From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 1F61A7FB13 for ; Thu, 4 Dec 2014 10:59:58 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of anders@fugmann.net) identity=pra; client-ip=90.184.182.235; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anders@fugmann.net"; x-sender="anders@fugmann.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of anders@fugmann.net designates 90.184.182.235 as permitted sender) identity=mailfrom; client-ip=90.184.182.235; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anders@fugmann.net"; x-sender="anders@fugmann.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@fw.fugmann.net) identity=helo; client-ip=90.184.182.235; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anders@fugmann.net"; x-sender="postmaster@fw.fugmann.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAMIvgFRauLbr/2dsb2JhbABag1hYgwXDT4YWAoEtAQEBAQF9hAMBAQQjFUARCxgCAgUWCAMCAgkDAgECATQRBgEMBgICiD4Jv1uWWwEBCAEBAQEBGQSBK4wEgz6CcYFRBZQmhAWDURCFaokSg2mDem6CRQEBAQ X-IPAS-Result: ArUEAMIvgFRauLbr/2dsb2JhbABag1hYgwXDT4YWAoEtAQEBAQF9hAMBAQQjFUARCxgCAgUWCAMCAgkDAgECATQRBgEMBgICiD4Jv1uWWwEBCAEBAQEBGQSBK4wEgz6CcYFRBZQmhAWDURCFaokSg2mDem6CRQEBAQ X-IronPort-AV: E=Sophos;i="5.07,514,1413237600"; d="scan'208";a="111029975" Received: from 0405ds1-vaer.1.fullrate.dk (HELO fw.fugmann.net) ([90.184.182.235]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 04 Dec 2014 10:59:57 +0100 Received: from [10.0.10.23] (issuu [195.184.103.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fw.fugmann.net (Postfix) with ESMTPSA id 7E6931692BE6; Thu, 4 Dec 2014 10:59:55 +0100 (CET) Message-ID: <5480309B.3020402@fugmann.net> Date: Thu, 04 Dec 2014 10:59:55 +0100 From: Anders Fugmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.0 MIME-Version: 1.0 To: Kenneth Adam Miller , caml users References: <54801373.3010506@fugmann.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Validation-by: anders@fugmann.net Subject: Re: [Caml-list] Potential OCaml-ZMQ memory management problems The garbage collector settings seems quite sane to me. You could try to force a major collection every call to iltrans. Gc.major () It could be that the segfault is really an out of memory situation. Maybe you have a leak in your code somewhere (Not releasing references to large objects). /Anders On 12/04/2014 09:02 AM, Kenneth Adam Miller wrote: > I'm using zmq and ocaml-zmq as installed by opam; I'm not at my work > computer or I would provide those details. > > Yes, I will try to work on creating a reproducible script > > Could it possibly be a call to Tunegc.set_gc () from > https://github.com/argp/bap/blob/master/ocaml/tunegc.ml ? > > I notice that this error didn't appear in single calls to my utility; > basically, I'm using iltrans from bap and I'm using it in a long living > process, unlike the current implementation which expects a few > transformations and then process death. I did notice that when I run it, > if I'm watching system monitor that it begins consuming vast amounts of > memory (quickly grows from a few megabytes to 800+) before it hits > segfault. Would there be any way to restore the aggressiveness of the GC > between calls to iltrans? > > On Thu, Dec 4, 2014 at 2:55 AM, Anders Fugmann > wrote: > > Hi Kenneth, > > The Ocaml-zmq code copies data from received messages into memory under > the control of the ocaml garbage collector, and immediatly frees the > ZMQ buffers. > > You do not need to explicitly free the data received from call to recv. > > Can you produce a small sample code that exposes the problem? We are > using the ocaml-zmq binding extensively, and have not seen any problems. > > If I were to take a wild guess, it either a mismatch between library > versions or the garbage-collector collecting the socket or zmq context. > > What version of the ocaml-zmq bindings and libzmq (c impl) are you > using? > > /Anders > > > > On 12/04/2014 07:09 AM, Kenneth Adam Miller wrote: > > I'm using ocaml-zmq (https://github.com/issuu/__ocaml-zmq > ) and I think I'm > encountering a memory management issue. I could be wrong > however, but > basically the issue (I think) is I have a rather large set of > messages > to send via zmq, and I'm getting a segfault. > > Does anybody know if I need to free the strings received from > zmq recv > functions in ocaml? If so how do I do that from ocaml? > > There's no code because this is just a general novice ocaml > questions. > > >