Leopold Toetsch wrote:
>
> Andy Dougherty <[EMAIL PROTECTED]> wrote:
> > On Thu, 3 Jul 2003, Juergen Boemmels wrote:
>
> >> more errors like this: t/op/interp_1.pasm and t/op/gc_1.t are the ones
> >> I know of. We will have much fun with bugs like this.
>
> > This might be another one -- t/op/gc_2.pasm is simply
>
> [ ... ]
>
> > I'm lost. Any suggestions?
>
> Probably a similar problem. During initialization the PIO subsystem
> creates the stdio objects, which are marked needing timely destruction.
> Now when you run a PASM file the code paths are different and some more
> PMCs might get created first or in different order, as it is when
> running a .PBC directly - though I don't have an explanation for this
> observed behavior.
>
> To furhter nail this down, I would disable TRACE_SYSTEM_AREAS in dod.c
> first.
Not having the guts to try looking in dod.c, I'd like to know: Does the
garbage collector look in the stack before, after, or elsewhen, from
when we mark PMCs and Buffers from our other roots?
If we can make sure that marking PMCs in the stack happens afterwards,
then we can set a breakpoint in the stack-walking part of the DOD, right
when we mark a a previously unmarked PMC -- this way we can see what
objects are made "live" by stack walking, as opposed to being reachable
through ordinary means. Then, in gdb, we look up the stack to whatever
the GC is looking at, and see if really is a proper pointer to a PMC.
Obviously, this means changing from:
mark roots from interpreter
mark pmcs on system stack
follow marked but previously unfollowed pmcs
to:
mark roots from interpreter
follow marked but previously unfollowed pmcs
mark pmcs on system stack
follow marked but previously unfollowed pmcs
But considering the potential benefit for debugging, it might be worth
it.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
