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