On Sunday 29 June 2008 16:16:13 Moritz Lenz wrote:
> > They almost definitely won't get fixed unless they're reported, and they
> > probably won't get fixed without simpler PIR examples.
>
> So how do we get simpler PIR examples?
Sometimes running:
$ parrot perl6.pbc --output=buggy.pir --trace=PIR buggy.p6
... and adding "load_bytecode 'perl6.pbc'" is enough.
Sometimes that gets you enough code to debug, and sometimes you can strip it
down. Experience helps. Maybe looking at the tests I added for the two
crashers Patrick reported in the previous week will help.
> And should I just report all GC issues even if they can't be reproduced
> in PIR?
> Do we even know if they *can* be reproduced in PIR at all?
They should all be reproducable in PIR, unless you're embedding libparrot and
doing something wrong there, or using NCI very badly. (I've done both.)
> I'm not too familiar with parrot's internals, but I could well imagine
> that a small memory corruption or GC oddity appears in some of the code
> that loads pbc files, or during any other operation that isn't executed
> (or executed differently) when loading and compiling PIR files.
>
> If we are truly out of luck, it might be some arithmetic bug which only
> manifests itself for larger bytecode files.
It's possible, but pretty unlikely; if bytecode is that badly damaged, we'd
see other crashes first.
-- c
