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 45E867FB0A for ; Mon, 8 Dec 2014 19:11:54 +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.214.178; 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.214.178 as permitted sender) identity=mailfrom; client-ip=209.85.214.178; 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-ob0-f178.google.com) identity=helo; client-ip=209.85.214.178; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="postmaster@mail-ob0-f178.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQBAJLohVTRVdaym2dsb2JhbABag1hcgwHBBIFgAQmGCQKBKQcWAQEBAQERAQEBAQEGCwsJFC6EAgEBAQMBEhEdARseAwELBgULDSoCAiEBAREBBQEcBhMiiAEBAwkIDbNZPTGLL4FsgwWLBQoZJw1ZhQYBAQEHAQEBAQEXAQUOjQd6gikLgjE+EYE2BYlCgnGFM4N0gUiBPYo1AoQIEiWBDYIFgjEhMIJDAQEB X-IPAS-Result: AlQBAJLohVTRVdaym2dsb2JhbABag1hcgwHBBIFgAQmGCQKBKQcWAQEBAQERAQEBAQEGCwsJFC6EAgEBAQMBEhEdARseAwELBgULDSoCAiEBAREBBQEcBhMiiAEBAwkIDbNZPTGLL4FsgwWLBQoZJw1ZhQYBAQEHAQEBAQEXAQUOjQd6gikLgjE+EYE2BYlCgnGFM4N0gUiBPYo1AoQIEiWBDYIFgjEhMIJDAQEB X-IronPort-AV: E=Sophos;i="5.07,539,1413237600"; d="scan'208";a="92417338" Received: from mail-ob0-f178.google.com ([209.85.214.178]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 08 Dec 2014 19:11:53 +0100 Received: by mail-ob0-f178.google.com with SMTP id gq1so4020348obb.23 for ; Mon, 08 Dec 2014 10:11:51 -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=QpdRc7xgGgPVBwth/zPZpldfRKo82HWIBx4AMIgZ9d4=; b=d+St3TjMbkE7bNeqavCt+Bb+hDrbXFQB30jORas76OEVGx50/tM1TaGtYPHOXnWlM6 XIPgHH1Nj4+6DzlHmVkvMDG3mK7DgrgvEDOGm0XlWWzAneLgKaaXTejSwjSCCagKmYWi m4CrR6lEuShRNdZtBWjQZEnbLz0MNUI94Uri+eIT+L9ayhL1skOyHhf/qOMoKyXzMOM/ 2e6SCW9ZHH7Usnm3eYEVW3iKeNPqKmnyXPrOEmJsjw0LIbcSFPhKReKVGRtAdsJmJc/6 HRJV7eUdWnghztYzFKz/daLw3U/3Pt6kCzUC+sjKiohjCXO9v03FrCrzsQvhSPSaAent MMdQ== MIME-Version: 1.0 X-Received: by 10.202.226.198 with SMTP id z189mr7699762oig.63.1418062311605; Mon, 08 Dec 2014 10:11:51 -0800 (PST) Received: by 10.182.197.1 with HTTP; Mon, 8 Dec 2014 10:11:51 -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:11:51 -0500 Message-ID: From: Kenneth Adam Miller To: caml users Content-Type: multipart/alternative; boundary=001a114091805a4c760509b85c78 Subject: Re: [Caml-list] Potential OCaml-ZMQ memory management problems --001a114091805a4c760509b85c78 Content-Type: text/plain; charset=UTF-8 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 >> >> >> > --001a114091805a4c760509b85c78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
While reproducing it, I found that in the bap/ocaml direct= ory'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.

But now I get a strange compiler error! I d= on't know how ocaml could be such a hard language to use...
<= br>
Input.inputs:=3Dref [];

Error: Unbou= nd 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 yo= u.

No, the backtrace in gdb is useless. All it says is:<= /div>
#0 =C2=A00x0000000000843033 =C2=A0in caml_c_call ()
#1 = =C2=A00x0000000000000000 =C2=A0in ?? ()

O= n Fri, Dec 5, 2014 at 4:14 AM, Anders Fugmann <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




--001a114091805a4c760509b85c78--