caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Yotam Barnoy <yotambarnoy@gmail.com>
To: Kenneth Adam Miller <kennethadammiller@gmail.com>
Cc: caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] Potential OCaml-ZMQ memory management problems
Date: Mon, 8 Dec 2014 13:16:09 -0500	[thread overview]
Message-ID: <CAN6ygOmKwW4AYYwmGTLHmM0e=ab=B6DjYGdFo65apdeLQ+yH+Q@mail.gmail.com> (raw)
In-Reply-To: <CAK7rcp-nO43phHKSKZKXLj6-=yw9XcyyoTnjyKNXTSuQCKjsDQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2536 bytes --]

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 <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
>>>
>>>
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4057 bytes --]

  reply	other threads:[~2014-12-08 18:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-04  6:09 Kenneth Adam Miller
2014-12-04  7:55 ` Anders Fugmann
2014-12-04  8:02   ` Kenneth Adam Miller
2014-12-04  9:59     ` Anders Fugmann
2014-12-04 10:04       ` Kenneth Adam Miller
2014-12-04 16:39         ` Kenneth Adam Miller
2014-12-04 16:45           ` Kenneth Adam Miller
2014-12-04 19:36             ` Anders Peter Fugmann
2014-12-04 21:48               ` Kenneth Adam Miller
2014-12-05  9:14                 ` Anders Fugmann
2014-12-05 14:38                   ` Kenneth Adam Miller
2014-12-08 18:11                     ` Kenneth Adam Miller
2014-12-08 18:16                       ` Yotam Barnoy [this message]
2014-12-08 18:19                         ` Kenneth Adam Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAN6ygOmKwW4AYYwmGTLHmM0e=ab=B6DjYGdFo65apdeLQ+yH+Q@mail.gmail.com' \
    --to=yotambarnoy@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=kennethadammiller@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).