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 389667FB13 for ; Thu, 4 Dec 2014 22:48:12 +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.49; 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.49 as permitted sender) identity=mailfrom; client-ip=209.85.218.49; 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-f49.google.com) identity=helo; client-ip=209.85.218.49; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="postmaster@mail-oi0-f49.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4BANvVgFTRVdoxm2dsb2JhbABZg1hYBIMBw06GFgKBGwcWAQEBAQERAQEBAQEGCwsJFC6EAgEBAQMBEhEdARseAwELBgUEBw0qAgIiAREBBQEcBhMiiAYBAwkJDbQTPTGLMIFsgweLLAoZJw1ZhR8BAQEBBgEBAQEBFwEBBA6NIYMzC4JxgVEFilOJU4Y0kiUSJYEQggmCOiEwgkUBAQE X-IPAS-Result: Av4BANvVgFTRVdoxm2dsb2JhbABZg1hYBIMBw06GFgKBGwcWAQEBAQERAQEBAQEGCwsJFC6EAgEBAQMBEhEdARseAwELBgUEBw0qAgIiAREBBQEcBhMiiAYBAwkJDbQTPTGLMIFsgweLLAoZJw1ZhR8BAQEBBgEBAQEBFwEBBA6NIYMzC4JxgVEFilOJU4Y0kiUSJYEQggmCOiEwgkUBAQE X-IronPort-AV: E=Sophos;i="5.07,518,1413237600"; d="scan'208";a="91709035" Received: from mail-oi0-f49.google.com ([209.85.218.49]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 04 Dec 2014 22:48:11 +0100 Received: by mail-oi0-f49.google.com with SMTP id i138so12793278oig.8 for ; Thu, 04 Dec 2014 13:48:09 -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=xg7MWtZtLnXlEIF+HIRUaE4WxJmkcToTXJgRtYDb5k0=; b=wFxLDpELg7xq9ACRmu542r/YePlDikx+u+q5HHWZIK4DIUaznejbJaamVGtbizsv0f yeHeGYs5ZSUQKbpYtMkei3ZOoSDZYH/ZMjcOdrO6HpXEZEiEOzw69JIpFEDOBdEeB5Zf sD1m7gBrST5WrkuHW9XWR9LfrdwnJBC8ebyXcWfS6jKDN1gbwCJKUHN7pziqpyxUWbWh SaR/RHbXoVm3ZwVFIYMh5egrBTJohRvWRQhjruMWzLUwPepxWMkMR6tD9QD05JcbpUWS iPpLsFQEeLvvJORoOk0/NvTsAbSWDwMetWFvXYHfKo5qgwMf+UjA6DcAO5kg30d3rAl9 ZqBA== MIME-Version: 1.0 X-Received: by 10.202.59.137 with SMTP id i131mr7744388oia.114.1417729689667; Thu, 04 Dec 2014 13:48:09 -0800 (PST) Received: by 10.182.197.1 with HTTP; Thu, 4 Dec 2014 13:48:09 -0800 (PST) In-Reply-To: <5480B7C3.90300@fugmann.net> References: <54801373.3010506@fugmann.net> <5480309B.3020402@fugmann.net> <5480B7C3.90300@fugmann.net> Date: Thu, 4 Dec 2014 16:48:09 -0500 Message-ID: From: Kenneth Adam Miller To: caml users Content-Type: multipart/alternative; boundary=001a113cc7f28a515c05096aeaec Subject: Re: [Caml-list] Potential OCaml-ZMQ memory management problems --001a113cc7f28a515c05096aeaec Content-Type: text/plain; charset=UTF-8 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? On Thu, Dec 4, 2014 at 2:36 PM, Anders Peter Fugmann wrote: > Sending data over a zmq socket should not cause a segfault. > > I suggest that you open an issue on > https://github.com/issuu/ocaml-zmq > with exact details of the segfault and we can take a stab at it. > > /Anders > > > On 04/12/14 17:45, Kenneth Adam Miller wrote: > >> Actually, I literally just found the location of the error... I'm trying >> to send some data from ocaml that is causing ZMQ to segfault... >> > > > --001a113cc7f28a515c05096aeaec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well I am just no thorough and you are correct.=C2=A0
=
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.=C2=A0

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

<= div>
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.=C2=A0

If I= turn off the tests prior to the segfaulting test, to_pb works in this part= icular run. But if the tests run before hand, something goes awry between t= he tests. Is it possible that to_pb is using some shared state between call= s?


On Thu, Dec 4, 2014 at 2:36 PM, Anders Peter Fugmann <an= ders@fugmann.net> wrote:
Sending data ove= r a zmq socket should not cause a segfault.

I suggest that you open an issue on
https://gi= thub.com/issuu/ocaml-zmq
with exact details of the segfault and we can take a stab at it.

/Anders


On 04/12/14 17:45, Kenneth Adam Miller wrote:
Actually, I literally just found the location of the error... I'm tryin= g
to send some data from ocaml that is causing ZMQ to segfault...



--001a113cc7f28a515c05096aeaec--