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]
