On Sunday 11 November 2007 21:56:28 Bob Rogers wrote:
> I've been seeing this for about two months now, with varying
> symptoms, but I've had no luck pinning it down. The Kea-CL release
> candidate on the Web site [1] displays the following symptoms with
> Parrot r21892 (i386, GNU/Linux):
>
> [EMAIL PROTECTED]> /usr/src/parrot/parrot kea.pbc
> Null PMC access in invoke()
> current instr.: 'COMMON-LISP;file_onload' pc 16446 (list.imc:5077)
> called from Sub 'lisp;COMMON-LISP;parrot_load' pc 3873 (kea.pir:1617)
> called from Sub 'lisp;COMMON-LISP;_main' pc 4185 (kea.pir:1716)
> [EMAIL PROTECTED]>
>
> For some reason a perfectly good sub defined in kea.pir is no longer
> there by the time it gets around to loading list.pbc (only the fourth
> one loaded during initialization). However, "parrot -G" makes it work.
> So far, it looks like a namespace GC bug.
>
> So I narrowed it down to working in r21269 but broken in r21270 (see
> comment below), which seems to have nothing to do with namespaces per
> se. However, several weeks ago I saw a segfault (reproducible at the
> time, but I no longer know which versions) in which Parrot was trying to
> resolve an HLL name to an ID during packfile loading and encountered a
> 0xdeadbeef string in the name-to-ID map, so perhaps it's not out of the
> question.
I think it's a freeze/thaw problem actually (as OrderedHash passes its tests
with the gcdebug core, but that is only meaningful if the test coverage is
good).
Is it a huge, invasive change to make Kea-CL *not* load PBC files, instead
loading PIR files? If you can do that for all files with subs in namespaces,
I'm curious to see if the problem goes away.
If so, that would make me think it's the freeze/thaw problem and give me a
place to dig into it.
Otherwise, the GC debugging tips on the wiki might help you narrow things down
further:
http://www.perlfoundation.org/parrot/index.cgi?fixing_gc_bugs
-- c
