On Sun Jan 20 19:11:26 2008, rgrjr wrote: > 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/ >
My apologies to your sanity, but with r25175 on osx/intel, this prints: hey, it's working. done.
