On Monday 21 April 2008 10:26:21 Clark Cooper wrote: > Using Parrot 0.6.1 on Fedora Core 5, linux 2.6.15-1.2054_FC5 > > The program, classinfo.pir : > ######################################################################### > .const string Indent=' ' > .const int MaxDepth = 6 > > .sub main :main > .param pmc argv > .local int argc > argc = argv > if argc >= 2 goto ok > > die "Need to provide a classname" > ok: > .local string classname > classname = argv[1] > $P0 = get_class classname > $I0 = defined $P0 > if $I0 goto valid > > die "Invalid classname" > > valid: > $P1 = inspect $P0 > $I0 = 0 > display_container($P1, $I0) > .end > > .sub display_container > .param pmc box > .param int level > .local pmc iter > .local pmc entry
With "string" instead of "pmc" for the register type, this code works. This makes me wonder what NameSpaces does for get_string_keyed versus get_pmc_keyed. > (gdb) r classinfo.pir Class > Starting program: /home/ccc/Parrot/parrot-0.6.1/parrot classinfo.pir Class > Reading symbols from shared object read from target memory...done. > Loaded system supplied DSO at 0x293000 > [Thread debugging using libthread_db enabled] > [New Thread -1208149824 (LWP 5015)] > name: String > namespace: NameSpace > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1208149824 (LWP 5015)] > 0x00552b57 in Parrot_Key_get_string (interp=0x875d008, pmc=0x893ed68) > at ./src/pmc/key.c:160 > 160 Parrot_Key_get_string(PARROT_INTERP, PMC *pmc) > (gdb) bt 6 > #0 0x00552b57 in Parrot_Key_get_string (interp=0x875d008, pmc=0x893ed68) > at ./src/pmc/key.c:160 > #1 0x0040d816 in key_string (interp=0x875d008, key=0x893ed68) at > src/key.c:402 #2 0x00552b81 in Parrot_Key_get_string (interp=0x875d008, > pmc=0x893ed68) at ./src/pmc/key.pmc:148 > #3 0x0040d816 in key_string (interp=0x875d008, key=0x893ed68) at > src/key.c:402 #4 0x00552b81 in Parrot_Key_get_string (interp=0x875d008, > pmc=0x893ed68) at ./src/pmc/key.pmc:148 > #5 0x0040d816 in key_string (interp=0x875d008, key=0x893ed68) at > src/key.c:402 (More stack frames follow...) That shouldn't happen, but it doesn't surprise me. -- c
