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