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