On 4/22/07, chromatic <[EMAIL PROTECTED]> wrote:
It came in just before the release and it touched a lot of files, so I (speaking only for myself) let it sit for a couple of days. Unfortunately, it also came in after Steve Peters's "No C++ Keywords" patch, so it didn't apply cleanly.

Thanks.  I should've checked that.

That's as far as I've been able to trace however. The tests do pass if I revert the patch. Any ideas?

I think the patch exposed either a GC or SMOP bug.  Here's the smallest I could 
get the test case and still have it segfault without gdb's help:

.sub _main :main
 load_bytecode 'library/Test/More.pir'

 # import test routines
 .local pmc exports, curr_namespace, test_namespace
 curr_namespace = get_namespace
 test_namespace = get_namespace [ "Test::More" ]
 exports = split " ", "plan ok is isa_ok"
 test_namespace.export_to(curr_namespace, exports)

 plan( 9 )

 $P0 = new 'SMOP_Attribute'
 isa_ok ($P0, 'SMOP_Attribute')

 $S1 = $P0.'name'()
 is ($S1, 'TestClass1', 'test the SMOP_Attribute name method')

 $P0 = new 'SMOP_Attribute'
 $S0 = $P0.'type'("TestTypeClass1")
 is ($S0, 'TestTypeClass1', 'test the SMOP_Attribute name method')

 $S1 = $P0.'type'()
 is ($S1, 'TestTypeClass1', 'test the SMOP_Attribute name method')
.end

However, we can make it segfault earlier using gdb, because the problem only 
shows up when a DOD run is triggered.  We can test whether the memory has been 
corrupted yet from anywhere in Parrot by issuing this:

call (*interp->arena_base->pmc_pool->more_objects)(interp, 
interp->arena_base->pmc_pool)

If it runs and exits, no problem.  If it segfaults, problem.  I was able to 
track the cause down to smop_init() in src/pmc/smop_attribute.pmc.  Running the 
aforementioned command before the call to mem_sys_allocate_zeroed() exits 
cleanly, but running it afterwards causes a segfault, so 
mem_sys_allocate_zeroed() (and the calloc() inside it) corrupts something.  
That's as far as I can get for now - looking at the code immediately preceding 
the segfault doesn't help any.

The exact same thing happens without the patch, but for some reason the test 
case above doesn't trigger a DOD run on an unpatched parrot, so it doesn't show 
up unless you use gdb.  At least it's Not My Fault(TM), but this one looks like 
a doozy to fix.  Someone more familiar with the garbage collector than I needs 
to sort this out.  Should we start a new ticket?

--
Alek Storm

Reply via email to