Subject:
Re: [ruby-ffi] Pointer Freeing Bug
From:
Mike Dalessio
Date:
1/6/10 1:12 PM
To:
ruby-ffi


On Wed, Jan 6, 2010 at 1:38 PM, Luis Lavena <luislavena@gmail.com> wrote:
On Wed, Jan 6, 2010 at 2:41 PM, JEG2 <james@graysoftinc.com> wrote:
> [...]
>
> I'm pretty sure I'm looking at a bug that's triggered during GC here.
>
> I thought the "ruby malloc" was a sign that Ruby is freeing up memory
> before it allocates more.
>
> Also, as I said, all of my tests work fine when run alone.  It's not
> until they are combined that the problem surfaces.  I assume it's the
> longer run triggering GC.

Yes, the nature of memory issues is that you may not necessarily trigger a segfault. Longer running code will, on average, tend to crash more often if there are memory issues.

I would advise you to try running your code under valgrind. If you're using hoe, you can install the hoe-debugging plugin to get easy-to-use rake tasks for this. Otherwise, you could check out my blog post on the subject:

http://flavoriffic.blogspot.com/2009/06/easily-valgrind-gdb-your-ruby-c.html


 
>
> Is this sounding right?
>
> I assume it almost has to be an FFI object being freed.  I mean, Ruby
> wouldn't try to free some memory allocated by Tokyo Cabinet, right?
> Are there FFI objects that try to free something as they are GCed?
>
> Any tips for the best way to isolate this issue are greatly
> appreciated.
>

What about forcing the garbage collect process on each spec?

That, in combination with running the specs in a verbose mode may
provide any indication of a individual test that is storing the
pointer in a variable that gets collected before it's time.

--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry



--
mike dalessio
mike@csa.net