Subject:
Re: [ruby-ffi] I can't figure out my memory leak
From:
Chuck Remes
Date:
5/7/10 1:28 PM
To:
ruby-ffi@googlegroups.com


On May 7, 2010, at 11:26 AM, Chuck Remes wrote:

> http://github.com/chuckremes/ffi-rzmq
> 
> I have a tremendous memory leak in my FFI code. I'm pretty sure I know exactly where it is caused but I have no idea how to solve it. This gist shows the code in question.
> 
> http://gist.github.com/393627
> 
> The first gist block is where I think the memory leak lives. The second gist block is the definition of the leaking Struct and the definitions of the library functions.
> 
> Here's the sequence of events for the creation of a message where message is not nil (from the constructor).
> 
> 1. Allocate the Msg_t Struct.
> 
> 2. Create a MemoryPointer from the message string to create the Msg_t payload.
> 
> 3. Hand off the Struct obj to the underlying library and tell the library the size needed to store the data.
> 
> 4. Hand off the MemoryPointer pointing to the message data to the underlying library. The library should now *own* the memory allocated in step #2 and manage it from here on.
> 
> 
> After a call is made to transmit OR receive the message obj, it calls Message#close. This makes a call to the underlying library to close the message and release its memory. This should release the memory that was allocated in #2 above. 

I made a little progress though the leak remains.

I talked with the library author and he set me straight on one of the calls. In step #3 even though we hand off a buffer we allocated to contain the payload, the library does not handle its deallocation. The handoff now includes a function callback to handle the deallocation. All the callback does is "ptr.free".

I have confirmed the callback is fired by having it print a statement. It is called for every message yet the leaking memory still grows at the same rate. :(

I looked at the source code for FFI and see that a call to MemoryPointer#free calls xfree immediately. So I'm still at a loss to explain the leakage. I'll try analyzing the JRuby heap to see if there are orphaned objects and where they are coming from.

cr