Hi, On Friday 12 March 2004 08:57, Leopold Toetsch wrote: > Jens Rieks <[EMAIL PROTECTED]> wrote: > > $ ../parrot dumper_1.imc > > parrot: src/packfile.c:2783: store_sub_in_namespace: Assertion `ns < > > pf->const_table->const_count' failed. > > aborted. > > Fails differently here: > > error:imcc:fixup_bsrs: couldn't find addr of sub '__lookup_method' This is printed here when running with valgrind, too.
==19374== Invalid read of size 4 ==19374== at 0x8146262: add_ns (symreg.c:336) ==19374== by 0x81463DE: _mk_address (symreg.c:372) ==19374== by 0x8146510: mk_sub_label (symreg.c:411) ==19374== by 0x813ED77: yyparse (imcc.y:459) ==19374== by 0x8144FD3: compile_file (imcc.l:835) ==19374== by 0x8152261: imcc_compile_file (parser_util.c:546) ==19374== by 0x416403F9: ??? ==19374== by 0x815D85F: Parrot_Compiler_invoke (compiler.c:56) ==19374== by 0x8080B1F: Parrot_load_bytecode (packfile.c:3051) ==19374== by 0x80C50BA: Parrot_load_bytecode_sc (core.ops:145) ==19374== by 0x8084631: runops_fast_core (runops_cores.c:51) ==19374== by 0x807AD0A: runops_int (interpreter.c:833) ==19374== by 0x807ADAC: runops_ex (interpreter.c:863) ==19374== by 0x807AF6F: runops (interpreter.c:921) ==19374== by 0x807B068: Parrot_runops_fromc (interpreter.c:990) ==19374== by 0x807B0B4: Parrot_runops_fromc_save (interpreter.c:1056) ==19374== by 0x807D47F: run_sub (packfile.c:254) ==19374== by 0x807D4D9: do_1_sub_pragma (packfile.c:279) ==19374== by 0x807D61C: do_sub_pragmas (packfile.c:325) ==19374== by 0x807D8D7: fixup_subs (packfile.c:445) ==19374== Address 0x430C8A7C is 0 bytes inside a block of size 72 free'd ==19374== at 0x4002CE27: free (in /usr/lib/valgrind/vgskin_memcheck.so) ==19374== by 0x814698C: free_sym (symreg.c:573) ==19374== by 0x8146DD6: clear_globals (symreg.c:725) ==19374== by 0x81451E1: imc_cleanup (imc.c:123) ==19374== by 0x8144FEF: compile_file (imcc.l:837) ==19374== by 0x8152261: imcc_compile_file (parser_util.c:546) ==19374== by 0x416403F9: ??? ==19374== by 0x815D85F: Parrot_Compiler_invoke (compiler.c:56) ==19374== by 0x8080B1F: Parrot_load_bytecode (packfile.c:3051) ==19374== by 0x80C50BA: Parrot_load_bytecode_sc (core.ops:145) ==19374== by 0x8084631: runops_fast_core (runops_cores.c:51) ==19374== by 0x807AD0A: runops_int (interpreter.c:833) ==19374== by 0x807ADAC: runops_ex (interpreter.c:863) ==19374== by 0x807AF6F: runops (interpreter.c:921) ==19374== by 0x807B068: Parrot_runops_fromc (interpreter.c:990) ==19374== by 0x807B0B4: Parrot_runops_fromc_save (interpreter.c:1056) ==19374== by 0x807D47F: run_sub (packfile.c:254) ==19374== by 0x807D4D9: do_1_sub_pragma (packfile.c:279) ==19374== by 0x807D61C: do_sub_pragmas (packfile.c:325) ==19374== by 0x807D8D7: fixup_subs (packfile.c:445) In symreg.c:336, !cur_namespace is true, but cur_namespace->name is NULL. This is avoided by... > The reason seems to be that (after loading some classes with namespace > directive): > > write fixup '_Data::Dumper::Default::__lookup_method' offs 508 > > the symbol suddenly appears in this namespace. Did you switch back to the > main namespace? > > namespace [""] .. adding a namespace statement at the top of each file Please have a look at the attached program, it seems to crash due to the same bug. $ tar xzf err3.tgz $ cd err3 $ ../parrot t/pmc/dumper_1.t > leo jens
err3.tgz
Description: application/tgz
