chromatic wrote: > On Sunday 29 June 2008 15:03:24 Moritz Lenz wrote: > >> I know of #55782. From time to time I encounter some GC weirdnesses, but >> so far I didn't care to report them all, because I have no way of to >> know if they have all the same root or not. > >> And as long as even the simplest programs in rakudo (like '1') fail with >> the gcdebug runcore I don't really know how to identify an offending >> construct in Perl 6 (if there is one). > > Let me repeat my offer from RT #55782: if someone hands me some PIR which > demonstrates any memory problem or crash in Parrot, I'll fix it.
So far I've never been able to do reproduce any of my bugs in PIR. I tried it a few times, but to no avail. > 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? 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? 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. I don't say it's likely to be any of the above cases, but at least it would explain why nobody found out what went wrong. Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
