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 C6C707FB0A for ; Mon, 8 Dec 2014 19:16:31 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yotambarnoy@gmail.com) identity=pra; client-ip=209.85.215.50; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of yotambarnoy@gmail.com designates 209.85.215.50 as permitted sender) identity=mailfrom; client-ip=209.85.215.50; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@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-la0-f50.google.com) identity=helo; client-ip=209.85.215.50; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-la0-f50.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMBAPLphVTRVdcym2dsb2JhbABag1hcgwHBBIFqhgkCgSkHFgEBAQEBEQEBAQEBBgsLCRQuhAIBAQEDARIRHQEbHQEDAQsGBQsNKgICIQEBEQEFARwGEyKIAQEDCQgNs1w9MYsvgWyDBYsFChknDVmFBgEBAQEBAQEBAgEBAQEBAQEBFAEFDo0HeoIpBAeCb4FHBYlCgnGFM4N0gUiBPYo1hAoSJYENggWCMSEwgkMBAQE X-IPAS-Result: AlMBAPLphVTRVdcym2dsb2JhbABag1hcgwHBBIFqhgkCgSkHFgEBAQEBEQEBAQEBBgsLCRQuhAIBAQEDARIRHQEbHQEDAQsGBQsNKgICIQEBEQEFARwGEyKIAQEDCQgNs1w9MYsvgWyDBYsFChknDVmFBgEBAQEBAQEBAgEBAQEBAQEBFAEFDo0HeoIpBAeCb4FHBYlCgnGFM4N0gUiBPYo1hAoSJYENggWCMSEwgkMBAQE X-IronPort-AV: E=Sophos;i="5.07,539,1413237600"; d="scan'208";a="92417663" Received: from mail-la0-f50.google.com ([209.85.215.50]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 08 Dec 2014 19:16:30 +0100 Received: by mail-la0-f50.google.com with SMTP id pn19so4409774lab.37 for ; Mon, 08 Dec 2014 10:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vW+qgP0Bz9XZ4lMawkpo6bZBOBCJB3v+Ev4iWaMgos0=; b=raSuA/JhlzF9jixWrwy3UbbEwjy5yjV1QYFKp/FrTri0N2YZn3y8tltbYRZPVug0OP f5HAoUvA+0/+gFwxTIKfh/t+zOwj6exNdnPBlBnb/9nxrftBeMm9zwGkePGdm6WmnAlu kkjcn0Sl9ow00wZrrfa3oRpfZiCbcQbjn2/SRoTmiNMdi8OwyhPmZIWCPWq33OledgtN 2NgePn7rQsjWovOR5Z5q3B5JC3RRsm68iAA8ssq4T2gIsV2yxEf8HDbhkFFdKmUx0sFK Af8tvUkS4rVPY5St73VxIuW96ZAsiTmv2OgPI54OwI/gZMNNyvmgV+YPtJtK519Z65fF U5pA== X-Received: by 10.153.7.170 with SMTP id dd10mr17474642lad.44.1418062590045; Mon, 08 Dec 2014 10:16:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.173.101 with HTTP; Mon, 8 Dec 2014 10:16:09 -0800 (PST) In-Reply-To: References: <54801373.3010506@fugmann.net> <5480309B.3020402@fugmann.net> <5480B7C3.90300@fugmann.net> <54817769.2050605@fugmann.net> From: Yotam Barnoy Date: Mon, 8 Dec 2014 13:16:09 -0500 Message-ID: To: Kenneth Adam Miller Cc: caml users Content-Type: multipart/alternative; boundary=001a113483aef2f6e30509b86c7c Subject: Re: [Caml-list] Potential OCaml-ZMQ memory management problems --001a113483aef2f6e30509b86c7c Content-Type: text/plain; charset=UTF-8 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 >>> >>> >>> >> > --001a113483aef2f6e30509b86c7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You didn't export inputs in Input.mli.

<= div>-Yotam

On Mon, Dec 8, 2014 at 1:11 PM, Kenneth Adam Miller = <kennet= hadammiller@gmail.com> wrote:
While reproducing it, I found that in the bap/ocaml dir= ectory's input.ml, th= ere is a mutable list that is being updated by functors in speclist when pa= rse_argv or parse is called; it retains the old list between calls to my fu= nction. So I need to reset it.

But = now I get a strange compiler error! I don't know how ocaml could be suc= h a hard language to use...

Input.inputs:=3Dref []= ;

Error: Unbound value Input.inputs

=
But you can know that I have included the ocaml directory and li= nked 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 fo= r you.

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

On Fri, Dec 5, 2014 at 4:14= AM, Anders Fugmann <anders@fugmann.net> wrote:
On 12/04/2014 10:48 PM, Kenneth Adam Miller wr= ote:
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





--001a113483aef2f6e30509b86c7c--