On Wed, 20 Nov 2002, Simon Glover wrote: > On Tue, 19 Nov 2002, Steve Fink wrote: > > ------------------------------------------------------------ > > t/op/lexicals.t 6 1536 6 6 100.00% 1-6 > > t/pmc/multiarra 2 512 3 2 66.67% 2-3 > > t/pmc/scratchpa 3 768 3 3 100.00% 1-3 > > I can get these to fail on Linux/x86 with gcc if I turn optimization on > (and only if running with --gc-debug). I would guess that it's some kind > of memory-related bug, but I haven't been able to track it down yet.
A bit more ... In particular, on Solaris, I've been able to track down one way of triggering the the t/op/lexicals.t failure to list.c. If I compile list.c without any optimization, the test passes. If I compile just the list_new function in list.c with the lowest optimization (-xO1, defined in the man page as "Does basic local optimization (peephole)"), those tests fail. All this happens only when $ENV{PARROT_GC_DEBUG} is set. Other optimization settings for other files make different tests fail. It's even weirder: If I apply the following silly one line patch to list_new, then I can get rid of the core dump. --- parrot-current/list.c Mon Nov 11 11:00:09 2002 +++ parrot-andy/list.c Wed Nov 20 16:18:19 2002 @@ -941,6 +941,7 @@ internal_exception(1, "N/Y\n"); break; } + printf("&list = %p\n", &list); return list; } Alternatively: If I apply the following silly one-line patch to dod.c, instead of my list.c patch, I get rid of the core dump. However, compiling dod.c without optimization doesn't get rid of the core dump. --- parrot-current/dod.c Wed Nov 6 11:00:15 2002 +++ parrot-andy/dod.c Wed Nov 20 16:33:19 2002 @@ -502,6 +502,7 @@ hi_var_ptr = lo_var_ptr; lo_var_ptr = tmp_ptr; } + printf("lo_var_ptr = %p\n", lo_var_ptr); /* Get the expected prefix */ prefix = mask & buffer_min; Next, if you apply my dod.c patch and then run ./parrot t/op/lexicals_1.pbc it will work ok, but if you run ./parrot t/op/lexicals_1.pbc | cat it will again coredump as before. Lastly, if you add an fflush(stdout) after that printf in dod.c, the core dump goes away again. I haven't sorted it all out. I can say that I haven't found anything wrong with list.c:list_new other than the fact that if type == enum_type_STRING, (list->chunk_list).version gets set to '1' in the unoptimized code and '0' in the optimized code. Manually fixing list_new to set it to '1' in all cases doesn't help, however. For those truly interested in the details, the failure for ./parrot t/op/lexicals_1.pbc is an unenlightening core dump. The "from" in chartype_lookup_transcoder is bogus. $ ./parrot t/op/lexicals_1.pbc Bus Error - core dumped $ dbx parrot coreq program terminated by signal BUS (invalid address alignment) Current function is chartype_lookup_transcoder 50 if ((transcoder = from->transcode_to(to->name)) == NULL) { (dbx) where =>[1] chartype_lookup_transcoder(from = 0x21, to = 0xc5a30), line 50 in "chartype.c" [2] string_transcode(interpreter = 0x15f478, src = 0x15f930, encoding = 0xc58b0, type = 0xc5a30, dest_ptr = (nil)), line 436 in "string.c" [3] string_compare(interpreter = 0x15f478, s1 = 0x15f930, s2 = 0x160250), line 834 in "string.c" [4] lexicals_get_position(interp = 0x15f478, lex = 0x169550, name = 0x160250), line 100 in "sub.c" [5] scratchpad_find(interp = 0x15f478, pad = 0x15f908, name = 0x160250, position = 0xffbef7c0), line 121 in "sub.c" [6] scratchpad_get(interp = 0x15f478, pad = 0x15f908, name = 0x160250, position = 0), line 226 in "sub.c" [7] Parrot_find_lex_p_sc(cur_opcode = 0x15f8b8, interpreter = 0xffbef8bc), line 3778 in "core.ops" [8] runops_fast_core(interpreter = 0x15f478, pc = 0x162338), line 34 in "runops_cores.c" [9] runops_generic(core = 0x2a4b8 = &runops_fast_core(struct Parrot_Interp *interpreter, opcode_t *pc), interpreter = 0x15f478, pc = 0x1622f0), line 46 in "interpreter.c" [10] runops(interpreter = 0x15f478, code = 0x1601f0, offset = 0), line 374 in "interpreter.c" [11] Parrot_runcode(interpreter = 0x15f478, argc = 1, argv = 0xffbefaa0), line 308 in "embed.c" [12] main(argc = 1, argv = 0xffbefaa0), line 51 in "test_main.c" And that concludes today's adventures. -- Andy Dougherty [EMAIL PROTECTED]