On Jan 5, 2011, at 11:38 AM, Alvaro wrote:

> 2011/1/5 Chuck Remes <cremes.devlist@mac.com>:

>> 
>> On Jan 5, 2011, at 7:51 AM, Alvaro wrote:
>> 

>>> I understand your point about how it works the garbage collection.
>>> Is a kind strange that the C lib purely don't have leaks but with the
>>> FFI binding it has and I couldn't find the reason yet, may be is
>>> inherited to ruby, I've tested it with Ree, Mri and JRuby without
>>> success.
>>> 
>>> I will continue trying to figure out what is happening, thanks for
>>> your comments.

>> 
>> Is this code public and available online somewhere? If so, someone on this list may get curious and look at it too.
>> 
>> It's possible, though unlikely, that the leak is in the FFI library. I had some massive leaks in a library I wrote using FFI, but I tracked 100% of them back to my own errors. There are now 0 leaks in the code (though I did find a few minor ones in each Ruby runtime).

> 
> The code is not public available, but I am pasting it here:
> http://pastie.org/private/lj5wqnlxdxwbe6ghjlpg

I recommend running your code under rubinius and using its heap dump to see where you are holding on to Ruby object references. Make sure you install at least version 1.2.0 (or master) and run "rbx docs" which will bring up a browser window (on OSX) with the latest documentation. Take a look at section 13 (Tools) and read through the memory analysis item.

I recommend taking a snapshot of your program after it has had 20 seconds or so to "warm up" and then do a second heap dump after the memory leak is obvious. Follow the documentation to get details on your object counts. Hopefully that will point you to the code that is holding onto references and causing your "leak."

cr