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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id D7D607FB0A for ; Mon, 8 Dec 2014 19:19:16 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of kennethadammiller@gmail.com) identity=pra; client-ip=209.85.218.43; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of kennethadammiller@gmail.com designates 209.85.218.43 as permitted sender) identity=mailfrom; client-ip=209.85.218.43; receiver=mail3-smtp-sop.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 (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-oi0-f43.google.com) identity=helo; client-ip=209.85.218.43; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="postmaster@mail-oi0-f43.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsBAPbqhVTRVdorlGdsb2JhbABag1hcgwHBBIFqhgkCgSoHFgEBAQEBEQEBAQEHCwsJEjCEAgEBAQMBEhEdARseAwELBgULDSoCAiEBAREBBQEcBhMiiAEBAwkIDbNhPTGLL4FsgwWLBwoZJw1ZhQYBAQEBBgEBAQEBFwEFDo0HeoIpC4JvgUcFiUKCcYUzg3SBSIENMIl5PIQKEiWBDYIFgjEhMIJDAQEB X-IPAS-Result: AlsBAPbqhVTRVdorlGdsb2JhbABag1hcgwHBBIFqhgkCgSoHFgEBAQEBEQEBAQEHCwsJEjCEAgEBAQMBEhEdARseAwELBgULDSoCAiEBAREBBQEcBhMiiAEBAwkIDbNhPTGLL4FsgwWLBwoZJw1ZhQYBAQEBBgEBAQEBFwEFDo0HeoIpC4JvgUcFiUKCcYUzg3SBSIENMIl5PIQKEiWBDYIFgjEhMIJDAQEB X-IronPort-AV: E=Sophos;i="5.07,539,1413237600"; d="scan'208";a="92417845" Received: from mail-oi0-f43.google.com ([209.85.218.43]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 08 Dec 2014 19:19:15 +0100 Received: by mail-oi0-f43.google.com with SMTP id a3so3760218oib.30 for ; Mon, 08 Dec 2014 10:19:14 -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=u4FsLJpuX9LUyK3uLVDr/ryRpkKEyzA8cmHdaQOGxc8=; b=N2flLdrals7I6+5BBFFE5KyYf67PI/eBhgKYdjUVXgzd+BQWzmdP5Dq22xEGmdv4ac 0molM7xpd2LqckBV0QKJ1AC/o4kXJgW7g0b97PS31hoEsI/+skyAMz5AT+DA3jv0ImBu 2ZSN+Z61mLBi0bW7eRtDoHeGzXH6bgCPKLglA98anl52SbFeQ/LAlc1rJR0NZGCa4tZr APvz469SC/YwpbE1ZHPnn3g5ivtCZcNIQJDAX//h+fZlJwAoAJmiBPWjBLFMmOriNe5f haYHK/SZY8i3dRffEw4pMQ/Wq/Yt4EvfZwFibs0rlGnfSMTXBpyuqAzKuCRMJ3bnyX4Z /fjA== MIME-Version: 1.0 X-Received: by 10.202.59.137 with SMTP id i131mr7693565oia.114.1418062753987; Mon, 08 Dec 2014 10:19:13 -0800 (PST) Received: by 10.182.197.1 with HTTP; Mon, 8 Dec 2014 10:19:13 -0800 (PST) In-Reply-To: References: <54801373.3010506@fugmann.net> <5480309B.3020402@fugmann.net> <5480B7C3.90300@fugmann.net> <54817769.2050605@fugmann.net> Date: Mon, 8 Dec 2014 13:19:13 -0500 Message-ID: From: Kenneth Adam Miller To: caml users Content-Type: multipart/alternative; boundary=001a113cc7f2b88d620509b87679 Subject: Re: [Caml-list] Potential OCaml-ZMQ memory management problems --001a113cc7f2b88d620509b87679 Content-Type: text/plain; charset=UTF-8 Excellent call. I find it is better to just update inputs in get_program and do a push request. It doesn't affect any existing program adversely and will only help others in the instance they reuse the function as I am. On Mon, Dec 8, 2014 at 1:16 PM, Yotam Barnoy wrote: > You didn't export inputs in Input.mli. > > -Yotam > > On Mon, Dec 8, 2014 at 1:11 PM, Kenneth Adam Miller < > kennethadammiller@gmail.com> wrote: > >> While reproducing it, I found that in the bap/ocaml directory's input.ml, >> there is a mutable list that is being updated by functors in speclist when >> parse_argv or parse is called; it retains the old list between calls to my >> function. So I need to reset it. >> (line 6 at https://github.com/argp/bap/blob/master/ocaml/input.ml) >> >> But now I get a strange compiler error! I don't know how ocaml could be >> such a hard language to use... >> >> Input.inputs:=ref []; >> >> Error: Unbound value Input.inputs >> >> But you can know that I have included the ocaml directory and linked it >> correct, since using Input.get_program already worked... >> >> On Fri, Dec 5, 2014 at 9:38 AM, Kenneth Adam Miller < >> kennethadammiller@gmail.com> wrote: >> >>> Yes, I'll try and recreate it for you. >>> >>> No, the backtrace in gdb is useless. All it says is: >>> #0 0x0000000000843033 in caml_c_call () >>> #1 0x0000000000000000 in ?? () >>> >>> On Fri, Dec 5, 2014 at 4:14 AM, Anders Fugmann >>> wrote: >>> >>>> On 12/04/2014 10:48 PM, Kenneth Adam Miller wrote: >>>> >>>>> Well I am just no thorough and you are correct. >>>>> >>>>> The sending of data over a zmq socket and the conversion of that data >>>>> from string to protobuf encoded string all occurred in one line. One I >>>>> added a print statement and then segregated them more cleanly, I can >>>>> see >>>>> that it is most certainly the line that converts to protobuf. >>>>> >>>>> The exact function that fails (on my end, could be deeper within this) >>>>> is to_pb from here: >>>>> >>>>> https://github.com/argp/bap/blob/master/ocaml/piqi/ast_piqi.ml#L186 >>>>> >>>>> In any case, I did a test, and in my first function when to_pb gets >>>>> called the first time and succeeds, I added an additional call to it... >>>>> which also succeeded. But then in a subsequent unit test, the one that >>>>> has been failing, still segfaults. >>>>> >>>>> If I turn off the tests prior to the segfaulting test, to_pb works in >>>>> this particular run. But if the tests run before hand, something goes >>>>> awry between the tests. Is it possible that to_pb is using some shared >>>>> state between calls? >>>>> >>>> >>>> I would not expect so. >>>> >>>> If you create a failing unittest that I could try? >>>> >>>> Also, does the segfault contain a usable back trace (using gdb)? That >>>> might give some insights into which code is failing. >>>> >>>> /Anders >>>> >>>> >>>> >>> >> > --001a113cc7f2b88d620509b87679 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Excellent call. I find it is better to just update inputs = in get_program and do a push request. It doesn't affect any existing pr= ogram adversely and will only help others in the instance they reuse the fu= nction as I am.

On Mon, Dec 8, 2014 at 1:16 PM, Yotam Barnoy <yotambarnoy@gmail.co= m> wrote:
= You didn't export inputs in Input.mli.

-Yotam

On Mon, Dec 8, 2014 at 1:11 PM, Kenneth Adam Miller <kennethadammiller@gmail.com> wrote:
While reproducing it, I found that in the ba= p/ocaml directory's input= .ml, there is a mutable list that is being updated by functors in specl= ist when parse_argv or parse is called; it retains the old list between cal= ls to my function. So I need to reset it.

But now I get a strange compiler error! I don't know how ocaml c= ould be such a hard language to use...

Input.input= s:=3Dref [];

Error: Unbound value Input.inputs

But you can know that I have included the ocaml direc= tory and linked it correct, since using Input.get_program already worked...=

On Fri, Dec 5, 2014 at 9:38 AM, Kenneth Adam Miller = <kennet= hadammiller@gmail.com> wrote:
Yes, I'll try and recreate it for you.

No, the backtrace in gdb is useless. All it says is:
#0 = =C2=A00x0000000000843033 =C2=A0in caml_c_call ()
#1 =C2=A00x00000= 00000000000 =C2=A0in ?? ()
=
On Fri, Dec 5, 2014 at 4:14 AM, Anders Fugma= nn <anders@fugmann.net> wrote:
On 12/04/2014 10:48 PM, Kenneth Adam Miller wrote:
Well I am just no thorough and you are correct.

The sending of data over a zmq socket and the conversion of that data
from string to protobuf encoded string all occurred in one line. One I
added a print statement and then segregated them more cleanly, I can see
that it is most certainly the line that converts to protobuf.

The exact function that fails (on my end, could be deeper within this)
is to_pb from here:

https://github.com/argp/bap/blob/master/ocaml= /piqi/ast_piqi.ml#L186

In any case, I did a test, and in my first function when to_pb gets
called the first time and succeeds, I added an additional call to it...
which also succeeded. But then in a subsequent unit test, the one that
has been failing, still segfaults.

If I turn off the tests prior to the segfaulting test, to_pb works in
this particular run. But if the tests run before hand, something goes
awry between the tests. Is it possible that to_pb is using some shared
state between calls?

 I would not expect so.

If you create a failing unittest that I could try?

Also, does the segfault contain a usable back trace (using gdb)? That might= give some insights into which code is failing.

/Anders






--001a113cc7f2b88d620509b87679--