On Fri, Jan 30, 2015 at 10:40 AM, Darryl L. Pierce <dpie...@redhat.com>
wrote:

> On Wed, Jan 28, 2015 at 01:22:45PM -0500, Rafael Schloming wrote:
> <snip>
> > Also, have you been able to validate your testing strategy for
> either/both
> > 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
> faults.
>
> 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.)

--Rafael

Reply via email to