From: "jared.r.richardson@..." <jared.r.richardson@...>
Date: 2006-07-21T22:40:07+09:00
Subject: Re: GC in C extension....

I think I've solved this... I assumed because the upper level arrays
were global that the contents would be safe. This was apparently not
the case. I added this line to protect the result set array

rb_global_variable(&resultset);

And it stopped corrupting. I think this call declares the variable to
the garbage collector so that it's aware not to clean up the contents.

I had already moved the other variables (there were three smaller
arrays) into C arrays that I convert to Ruby arrays when the client
program calls for them. I did this rather than create the Ruby arrays
earlier in the program and let them sit, waiting to be retrieved by the
caller. It was during the "waiting" time that the corruption was
occurring.

Jared
http://jaredrichardson.net

jared.r.richardson@gmail.com wrote:
> Hi all,
>
> I'm working on a database driver for the Ingres database and I'm nearly
> done but I've got one outstanding issue. Initially I thought it was a
> bug in rb_ary_new but now I'm wonding if it's a problem with garbage
> collection.
>
> I have several arrays that I declare globally in my C code. Each holds
> a collection of VALUE objects that are created locally within the
> routines. The contents of the arrays (the VALUE objects) will
> eventually corrupt on a long running program. (If it matters, the
> largest of these arrays is an array of arrays holding a result set.)
>
> I've traced the corruption to a rb_ary_new call. On the line before the
> rb_ary_new, the data within the array is good. On the line after,
> trying to print the data causes a segmentation fault.
>
> So my question is this: will the GC collect a VALUE object that lives
> within a global array? I thought storing the local variables withing a
> global variable would be a good enough reference to keep the data safe.
>
> Any thoughts would be appreciated!
> 
> Jared
> http://jaredrichardson.net