On Fri, Jan 30, 2015 at 10:40 AM, Darryl L. Pierce <dpie...@redhat.com>
> On Wed, Jan 28, 2015 at 01:22:45PM -0500, Rafael Schloming wrote:
> > Also, have you been able to validate your testing strategy for
> > of these POCs? Can you generate seg faults and/or valgrind warnings when
> > you intentionally comment out the line of code that keeps the reference
> > alive?
> The POC that uses manual wrapping of a C struct works correctly,
> preventing objects from being reaped without leaking memory.
> I validated this by creating exhaustive (1M+) instances of both pure Ruby
> and C structs that have been wrapped via the Data_Wrap_Struct, assigning
> the Ruby object to the C struct so that only C held a reference to it,
> then calling GC.start to reap objects and then checking that the
> expected number of the pure Ruby objects still existed, via
> ObjectSpace.each_object([class]).count. Accessing the C-help Ruby object
> and doing functions such as class_eval on it worked without segmentation
> I then ensures that it wasn't a fluke by commenting out, in the function
> that marks the Ruby object in C to keep it from being reaped, and
> re-running the tests. The app *immediately* segfaults after trying to
> class_eval the first Ruby object after garbage collection.
> So this path is the right one to follow.
This sounds promising, is there any way you could highlight the key bits to
look at on the branch you pointed to? Maybe post it in a way that would
permit line by line comments? (My git-fu isn't super strong, so if there's
already a way to do this with what you posted I apologize for the request.)