# New Ticket Created by Bob Rogers # Please include the string: [perl #50040] # in the subject line of all future correspondence about this issue. # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=50040 >
The attached tarball has a test case in which one file
(gc-debug-test.pir) loads another (structures.pir), where the second has
a :load sub that calls a sub defined in the first file. The bug is
that, under what must be fairly arcane conditions, get_hll_global in the
:load sub doesn't find the sub defined in the main file. To reproduce,
unpack the tarball, edit the makefile macros to point to your Parrot
instance, and type "make". You should get a "couldn't find
_fdefn_init_kludge" error. If it fails to fail, it will say "hey, it's
working", and exit normally.
I've been seeing this problem intermittently for at least three or
four months now, but had never been able to isolate a test case until I
tried specifying --runcore=gcdebug (chromatic++!) while tracking down
another problem (which may be related). It fails reliably for me on
GNU/Linux with x86 in Parrot r25001 and r25076, using two separate
distro versions.
Some additional clues:
1. It appears to require not only loading the pmclass via .HLL, but
doing a get_class of that pmclass before loading structures.pbc file.
2. Trimming any more subs out of structures.pir makes it work.
(There are dependencies between the :load subs, so work backwards from
the next-to-last one.) If it works for you off the bat, you may be on
the other side of some internal threshold; rename orig-structures.pir to
structures.pir and try again.
3. And, of course, it needs --runcore=gcdebug to fail.
This is my current roadblock, so I'll continue looking at it, but I
would be exceedingly grateful for any help. Just knowing that someone
else can reproduce this would be very good for my sanity.
TIA,
-- Bob Rogers
http://rgrjr.dyndns.org/
gc-bug.tgz
Description: Binary data
