On Monday 05 May 2008 12:17:39 Mark Glines wrote: > [this is a resend; first one apparently didn't get through.] > > > There is a TODO comment in this function, which has been there for > quite some time. We need to figure out if this is still valid, and > either make the change, or remove the comment. > > From src/packfile.c: > > /* > * TODO use thaw_constants > * current issue: a constant Sub with attached properties > * doesn't DOD mark the properties > * for a constant PMC *all* contents have to be in the constant pools > */ pmc = Parrot_thaw(interp, image);
Parrot_thaw() and whatever it calls to create new PMCs doesn't know to allocate all GCable elements reachable from a constant PMC from constant pools themselves. Constant GCable elements get marked during the mark phase if and only if they're reachable from the root set AND (most importantly) if there's a path through the graph to them that goes through a PMC that's not already marked as live for this mark phase. Constant GCable elements never get their live flags flipped back to unknown during the sweep phase. They never get collected, so this is only a problem when... ... any non-constant GCable element reachable only from a constant PMC will be marked as live when its parent is first marked as live. The sweep phase will unmark the non-constant element. The next mark phase will *not* mark the non-constant element as live (because its parent is still live), and the subsequent sweep phase will collect that element... > I noticed this comment while looking into that Parrot_thaw line for other > reasons... specifically, valgrind is reporting a leak from this line. > > So I was curious. I changed Parrot_thaw to Parrot_thaw_constant, and it > built fine. But the change causes the following tests to fail: > > Failed Test Stat Wstat Total Fail List of Failed > --------------------------------------------------------------------------- >---- t/library/iter.t 0 11 47 42 27-47 > t/library/range.t 0 11 78 80 39-78 > t/op/cmp-nonbranch.t 0 11 88 58 60-88 > t/pmc/hash.t 1 256 147 242 27-147 > t/pmc/n_arithmetics.t 0 11 73 70 39-73 > > > 4 out of 5 of those failures are caused by a segfault in mmd_distance(): > Program received signal SIGSEGV, Segmentation fault. > (gdb) print multi_sig->vtable > $4 = (VTABLE *) 0xdeadbeef ... which is exactly what you see here. -- c
