ok, I tried it with Gc.major() and Gc.minor(); and that didn't eliminate the segfault.

There's an issue with debugging too; when I compile my unit tests for debugging or byte code, it reports parameters not being found (as in the string returned from ZMQ is empty), even though a simple recompile with native code makes that specific mysterious error go away. In any case, because it does not receive the parameters while compiled for debug or byte code, it cannot proceed to the point where the segfault occurs. Also, just removing some of the preceeding tests in order that they not be in the way when compiled for byte or debug code causes the segfault to not occur...

How do I debug this in binary mode?

On Thu, Dec 4, 2014 at 5:04 AM, Kenneth Adam Miller <kennethadammiller@gmail.com> wrote:

Ok I'll give that a shot when I get a chance to edit it. Thanks, gc.major... I'm new to ocaml and I'm still reading through RWO, on chapter 9 learning about how modules compose nicely :)

On Thu, Dec 4, 2014 at 4:59 AM, Anders Fugmann <anders@fugmann.net> wrote:
The garbage collector settings seems quite sane to me. You could try to force a major collection every call to iltrans.

Gc.major ()

It could be that the segfault is really an out of memory situation. Maybe you have a leak in your code somewhere (Not releasing references to large objects).

/Anders

On 12/04/2014 09:02 AM, Kenneth Adam Miller wrote:

I'm using zmq and ocaml-zmq as installed by opam; I'm not at my work
computer or I would provide those details.

Yes, I will try to work on creating a reproducible script

Could it possibly be a call to Tunegc.set_gc () from
https://github.com/argp/bap/blob/master/ocaml/tunegc.ml ?

I notice that this error didn't appear in single calls to my utility;
basically, I'm using iltrans from bap and I'm using it in a long living
process, unlike the current implementation which expects a few
transformations and then process death. I did notice that when I run it,
if I'm watching system monitor that it begins consuming vast amounts of
memory (quickly grows from a few megabytes to 800+) before it hits
segfault. Would there be any way to restore the aggressiveness of the GC
between calls to iltrans?

On Thu, Dec 4, 2014 at 2:55 AM, Anders Fugmann <anders@fugmann.net
<mailto:anders@fugmann.net>> wrote:

Hi Kenneth,

The Ocaml-zmq code copies data from received messages into memory under
the control of the ocaml garbage collector, and immediatly frees the
ZMQ buffers.

You do not need to explicitly free the data received from call to recv.

Can you produce a small sample code that exposes the problem? We are
using the ocaml-zmq binding extensively, and have not seen any problems.

If I were to take a wild guess, it either a mismatch between library
versions or the garbage-collector collecting the socket or zmq context.

What version of the ocaml-zmq bindings and libzmq (c impl) are you
using?

/Anders

On 12/04/2014 07:09 AM, Kenneth Adam Miller wrote:

I'm using ocaml-zmq (https://github.com/issuu/__ocaml-zmq
<https://github.com/issuu/ocaml-zmq>) and I think I'm
encountering a memory management issue. I could be wrong
however, but
basically the issue (I think) is I have a rather large set of
messages
to send via zmq, and I'm getting a segfault.

Does anybody know if I need to free the strings received from
zmq recv
functions in ocaml? If so how do I do that from ocaml?

There's no code because this is just a general novice ocaml
questions.