Re: [Caml-list] Potential OCaml-ZMQ memory management problems

[Kenneth Adam Miller <kennethadammiller@gmail.com>]

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

Excellent call. I find it is better to just update inputs in get_program
and do a push request. It doesn't affect any existing program adversely and
will only help others in the instance they reuse the function as I am.

On Mon, Dec 8, 2014 at 1:16 PM, Yotam Barnoy <yotambarnoy@gmail.com> wrote:

> 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: 4734 bytes --]