On Fri, Jan 30, 2015 at 10:40 AM, Darryl L. Pierce <[email protected]> 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
