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 3DE247FB13 for ; Thu, 4 Dec 2014 09:02:31 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of kennethadammiller@gmail.com) identity=pra; client-ip=209.85.192.49; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of kennethadammiller@gmail.com designates 209.85.192.49 as permitted sender) identity=mailfrom; client-ip=209.85.192.49; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; 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@mail-qg0-f49.google.com) identity=helo; client-ip=209.85.192.49; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="postmaster@mail-qg0-f49.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgBAMwUgFTRVcAxm2dsb2JhbABag1hYBIMBw1CGFgKBDwcWAQEBAQERAQEBAQEGCwsJFC6EAgEBAQMBEhEdARseAwELBgUEBw0qAgIiAREBBQEcBhMiiAYBAwkJDbMhPTGLMIFsgweLNAoZJw1ZhQUBAQEBBgEBAQEBFwEBBA6NIYMzC4JxgVEFilOJU4QFgi+BMpByEiWBEIIJgjohMIJFAQEB X-IPAS-Result: ArgBAMwUgFTRVcAxm2dsb2JhbABag1hYBIMBw1CGFgKBDwcWAQEBAQERAQEBAQEGCwsJFC6EAgEBAQMBEhEdARseAwELBgUEBw0qAgIiAREBBQEcBhMiiAYBAwkJDbMhPTGLMIFsgweLNAoZJw1ZhQUBAQEBBgEBAQEBFwEBBA6NIYMzC4JxgVEFilOJU4QFgi+BMpByEiWBEIIJgjohMIJFAQEB X-IronPort-AV: E=Sophos;i="5.07,514,1413237600"; d="scan'208";a="111004106" Received: from mail-qg0-f49.google.com ([209.85.192.49]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 04 Dec 2014 09:02:30 +0100 Received: by mail-qg0-f49.google.com with SMTP id a108so12223244qge.36 for ; Thu, 04 Dec 2014 00:02:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=x4/f0hkavDreoNw3u93/ISvCjOf8LoOBgA024CECTFk=; b=iZFFiPRVhPd9zpxs8UlnIIdgAR9p8X6p4z+pmmSEBODorVzReVKBHYi3iOP/2EdGa8 UdO6csai+eysAfdJNlbwOlbx9fS67NsQz2VcW7NURv/SV8PYLdDWW6flCta00He07zz2 nGzjQ8UxisYQDX5ocU1WbcFTZLEnJTkpLtRuTLnoh2kIgXYPxqYXBqY5Lk4wVi8pxm9z JA0+zZRzmVki75ul+afQY9p3cl6EqUagpQ0glM+hlNPEXEmFymavtfeSpJyeYfpj10QW 8JqLZkWSu/26ExzhxZMYGNgKWJstFaSAA4mz88ASqd/ZQ0SgE2RajQCg+udVidNY3D4p cPFw== MIME-Version: 1.0 X-Received: by 10.140.93.49 with SMTP id c46mr14352716qge.58.1417680149409; Thu, 04 Dec 2014 00:02:29 -0800 (PST) Received: by 10.140.102.21 with HTTP; Thu, 4 Dec 2014 00:02:29 -0800 (PST) In-Reply-To: <54801373.3010506@fugmann.net> References: <54801373.3010506@fugmann.net> Date: Thu, 4 Dec 2014 03:02:29 -0500 Message-ID: From: Kenneth Adam Miller To: caml users Content-Type: multipart/alternative; boundary=001a113a4d22b5f70505095f6110 Subject: Re: [Caml-list] Potential OCaml-ZMQ memory management problems --001a113a4d22b5f70505095f6110 Content-Type: text/plain; charset=UTF-8 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. >> > > --001a113a4d22b5f70505095f6110 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm using zmq and ocaml-zmq as installed by opam; I= 9;m not at my work computer or I would provide those details.

Yes, I will try to work on creating a reproducible script
<= br>
Could it possibly be a call to Tunegc.set_gc () from=C2=A0https://gi= thub.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 l= iving process, unlike the current implementation which expects a few transf= ormations 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 <anders@fugmann.net= > 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 bu= ffers.

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 versio= ns 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.<= br>


--001a113a4d22b5f70505095f6110--