On Thursday 07 February 2008 07:31:44 Patrick R. Michaud wrote:
> I'll leave this ticket open for now, in case one of the Parrot GC
> hackers wants to try to track it down.
You make it sound as if there's more than one!
I don't think it's a GC problem though. Run the original program (or any
Rakudo program) with parrot and the --leak-test flag:
$ ../../parrot --leak-test perl6.pbc -e 1
You should get an abort, depending on how your libc feels about freeing the
same pointer twice.
The problem is that when we destroy the vtables (which we only do
with --leak-test, as there's little point in freeing a bunch of memory when
we're just going to exit anyway), a subclass of Class has the same
ro_variant_vtable as Class, which isn't exactly right. There are
Parrot_clone_vtable() calls in all the places I expect, but there's a
misassignment somewhere that's apparently doing the wrong thing.
(Alternately, it *is* a memory problem, with some pointer writing over random
memory randomly, in which case we're lucky it does so in such a way that
looks like this vtable problem.)
In this case, it's the Perl6Object class. You can get the same result with
this simple PIR program:
.sub 'main'
$P0 = newclass 'KABLOOIE'
.end
Again, run it with --leak-test for maximum fireworkage.
I'll keep working on it.
-- c
