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 ED1A17FB30 for ; Fri, 5 Dec 2014 15:38:49 +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.170; 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.170 as permitted sender) identity=mailfrom; client-ip=209.85.214.170; 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-f170.google.com) identity=helo; client-ip=209.85.214.170; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="postmaster@mail-ob0-f170.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgBAGHCgVTRVdaqm2dsb2JhbABZg1hYBIMBw0ABCYYTAoEWBxYBAQEBAREBAQEBAQYLCwkULoQCAQEBAwESER0BGx4DAQsGBQQHDSoCAiIBEQEFARwGEyKIAwEDCQkNs2I9MYsvgWyDBYsxChknDVmFHAEBAQEGAQEBAQEXAQEEDo0agyMLgjE+EYE2BYowgyyFaIYbkVESJYENggWCMiEwgkMBAQE X-IPAS-Result: AlgBAGHCgVTRVdaqm2dsb2JhbABZg1hYBIMBw0ABCYYTAoEWBxYBAQEBAREBAQEBAQYLCwkULoQCAQEBAwESER0BGx4DAQsGBQQHDSoCAiIBEQEFARwGEyKIAwEDCQkNs2I9MYsvgWyDBYsxChknDVmFHAEBAQEGAQEBAQEXAQEEDo0agyMLgjE+EYE2BYowgyyFaIYbkVESJYENggWCMiEwgkMBAQE X-IronPort-AV: E=Sophos;i="5.07,522,1413237600"; d="scan'208";a="92047704" Received: from mail-ob0-f170.google.com ([209.85.214.170]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 05 Dec 2014 15:38:49 +0100 Received: by mail-ob0-f170.google.com with SMTP id wp18so594028obc.1 for ; Fri, 05 Dec 2014 06:38:47 -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=jVBEMdKGh11JO48MTE5ChkPpuY/PojFg/Ito+uxubg4=; b=WKaCznuIUi9ZMFMBWZuqzk72AYPcONJVUTjEDY1znsAEZWH8eM0hMCoGOTfxdF/Wo4 tEcp/3bc2yDB8bMELanszSby0A6L4YAlskma4lJrO1g6R+0jbJ+7r5LVLkosM0AmCxY+ NRGJ07z2YWg+c8TDNUND2I8clNS4Xi/9X2WyJk0UDrFUgx08p1Y4khOOQVcAWxM2VG4A qSa0GvibjLWBjJ+Y9qBKFIiVaNqeIY+c+LAgz/Zi40CgM1mJnFqmaugAtiyag5pIbQGp jPQfx2IASUWtH2sGA6+BwbSV/nmhNe1qOG67VUks7f6RKNpHaFZGnCdolm+am36lQijz LClg== MIME-Version: 1.0 X-Received: by 10.202.177.65 with SMTP id a62mr10532028oif.92.1417790327687; Fri, 05 Dec 2014 06:38:47 -0800 (PST) Received: by 10.182.197.1 with HTTP; Fri, 5 Dec 2014 06:38:47 -0800 (PST) In-Reply-To: <54817769.2050605@fugmann.net> References: <54801373.3010506@fugmann.net> <5480309B.3020402@fugmann.net> <5480B7C3.90300@fugmann.net> <54817769.2050605@fugmann.net> Date: Fri, 5 Dec 2014 09:38:47 -0500 Message-ID: From: Kenneth Adam Miller To: caml users Content-Type: multipart/alternative; boundary=001a113ce1f8d9144705097908b8 Subject: Re: [Caml-list] Potential OCaml-ZMQ memory management problems --001a113ce1f8d9144705097908b8 Content-Type: text/plain; charset=UTF-8 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 > > > --001a113ce1f8d9144705097908b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, I'll try and recreate it for you.

<= div>No, the backtrace in gdb is useless. All it says is:
#0 =C2= =A00x0000000000843033 =C2=A0in caml_c_call ()
#1 =C2=A00x00000000= 00000000 =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 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



--001a113ce1f8d9144705097908b8--