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

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

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

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

[-- Attachment #2: Type: text/html, Size: 5363 bytes --]