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.
But I'm still stumped. Any ideas?
TIA,
-- Bob Rogers
http://rgrjr.dyndns.org/
[1] http://rgrjr.dyndns.org/lisp/kea-cl/kea-cl-0.4.17.tgz; this bug is
largely why I haven't released it.
------------------------------------------------------------------------
r21270 | chromatic | 2007-09-13 21:15:24 -0400 (Thu, 13 Sep 2007) | 7 lines
[src] Continued refactoring of HLL subsystem. This change uses an OrderedHash
instead of a ResizablePMCArray to hold HLL information. While existing
external code looks up HLL information by index, now looking up HLL information
by HLL name is an O(1) operation, not an O(n/2) operation.
All tests pass on 32-bit x86 Linux, particularly PGE and TGE. As well, Perl 6,
Pheme, Lua, and Tcl all pass their expected tests.
