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