Tinderbox
Steve Fink
can actually see some green again!
On the other hand, everything else is still failing. I tried compiling
on a Solaris box, but the darned thing worked flawlessly. Here's a
summary of what's going wrong on the various tinderboxen; anybody have
any details on any of them?
### adrastea (Debian PPC) ###
Appears to mostly be the known sprintf problems.
Failed Test Status Wstat Total Fail Failed List of Failed
----------------------------------------------------------------
t/op/interp.t 1 256 2 1 50.00% 2
t/op/string.t 1 256 98 1 1.02% 89
t/pmc/perlhash.t 1 256 21 1 4.76% 17
t/src/sprintf.t 1 256 2 1 50.00% 1
### frivolous (Solaris 9 on Sparc; gcc-3.1) ###
Looks like it crashed in the hashtable test. Why???
Failed Test Stat Wstat Total Fail Failed List of Failed
--------------------------------------------------------------
t/pmc/perlhash.t 1 256 21 1 4.76% 17
### galactic-lcc (Debian x86, lcc 4.1) ###
Failed the "mod_n" test in number.t, and the "pushn & popn (deep)"
test in stacks.t.
Failed Test Status Wstat Total Fail Failed List of Failed
-------------------------------------------------------------
t/op/number.t 1 256 32 1 3.12% 10
t/op/stacks.t 1 256 35 1 2.86% 34
### galactic-tcc (Debian x86, tcc 4.0 (TenDRA-4.1.2)) ###
Same machine, different compiler: one test now works, one still
breaks, and a new one breaks. Odd.
Failed Test Status Wstat Total Fail Failed List of Failed
------------------------------------------------------------------
t/op/stacks.t 1 256 35 1 2.86% 34
t/pmc/multiarray.t 2 512 3 2 66.67% 2-3
### glastig (Mac OS X 10.1) ###
I've seen this message before, but I thought it was fixed now:
"find_type returned 0 for illegal wanted -68". The next failure is
similar: "Sub PMCs should be type 17 but have incorrect type 16".
That's a test I added when debugging the previous message. Seems like
the type info is stale or something.
Failed Test Status Wstat Total Fail Failed List of failed
------------------------------------------------------------
t/op/types.t 1 256 1 1 100.00% 1
t/pmc/pmc.t 1 256 79 1 1.27% 71
t/pmc/sub.t 1 256 3 1 33.33% 1
### momentum (IRIX 6.5), MIPSpro 7.30 ###
Hmmm... we've seen these same two tests fail before, on
galactic-tcc. Interesting.
Failed Test Status Wstat Total Fail Failed List of failed
------------------------------------------------------------
t/pmc/multiarra 2 512 3 2 66.67% 2-3
### TD-Camaro (Compaq Tru64 Unix 5.1a) ###
It must all mean something...
Failed Test Status Wstat Total Fail Failed List of failed
------------------------------------------------------------
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
### TD-Camry (Red Hat Linux 7.1 on Alpha) ###
This one has a mind (or bug?) of its own.
Failed Test Status Wstat Total Fail Failed List of Failed
------------------------------------------------------------------
t/op/lexicals.t 6 1536 6 6 100.00% 1-6
t/pmc/scratchpad.t 3 768 3 3 100.00% 1-3
### TD-Corvette (Compaq Tru64 Unix 4.0g) ###
An interesting assortment -- same as the previous, plus the recurring
multiarray 2-3 failures.
Failed Test Status Wstat Total Fail Failed List of Failed
------------------------------------------------------------------
t/op/lexicals.t 6 1536 6 6 100.00% 1-6
t/pmc/multiarray.t 2 512 3 2 66.67% 2-3
t/pmc/scratchpad.t 3 768 3 3 100.00% 1-3
Dan Sugalski
>### glastig (Mac OS X 10.1) ###
>
>I've seen this message before, but I thought it was fixed now:
>"find_type returned 0 for illegal wanted -68". The next failure is
>similar: "Sub PMCs should be type 17 but have incorrect type 16".
>That's a test I added when debugging the previous message. Seems like
>the type info is stale or something.
>
> Failed Test Status Wstat Total Fail Failed List of failed
> ------------------------------------------------------------
> t/op/types.t 1 256 1 1 100.00% 1
> t/pmc/pmc.t 1 256 79 1 1.27% 71
> t/pmc/sub.t 1 256 3 1 33.33% 1
Probably stale objects in there somewhere. I'll blow away the whole
directory and start clean to see where we go from there.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Josh Wilmes
> ### galactic-lcc (Debian x86, lcc 4.1) ###
>
> Failed the "mod_n" test in number.t, and the "pushn & popn (deep)"
> test in stacks.t.
Not sure what the story is with pushn/popn, but the mod_n failure is normal
for lcc- it appears to provide a slightly broken % operator.
--Josh
Kj
st...@fink.com (Steve Fink) wrote:
[snip]
> ### glastig (Mac OS X 10.1) ###
>
> I've seen this message before, but I thought it was fixed now:
> "find_type returned 0 for illegal wanted -68". The next failure is
> similar: "Sub PMCs should be type 17 but have incorrect type 16".
> That's a test I added when debugging the previous message. Seems like
> the type info is stale or something.
>
> Failed Test Status Wstat Total Fail Failed List of failed
> ------------------------------------------------------------
> t/op/types.t 1 256 1 1 100.00% 1
> t/pmc/pmc.t 1 256 79 1 1.27% 71
> t/pmc/sub.t 1 256 3 1 33.33% 1
[snip]
Hello Steve,
Last I heard, glastig was running Mac OS X 10.2.2 with the stock
Jaguar compiler. Incidentally, I'm running Mac OS X 10.1.5 with both
the stable and beta compilers. I'll post to the ng with the results of
today's CVS if it looks different than what I reported earlier (which
was failures 1-6 of t/op/lexicals.t and 1-3 of t/pmc/scratchpad.t with
the 2.95.2-derived stable (which is of course different than the Jaguar
stable) and no failures with the beta (3.1-derived, but derived from a
release before the Jaguar stock compiler).
Cheers,
~kj
Leopold Toetsch
> Looks like somebody gave the TD-* machines the correct input. Yay! We
> can actually see some green again!
> t/op/interp.t 1 256 2 1 50.00% 2
unimp restart on PPC
> t/op/lexicals.t 6 1536 6 6 100.00% 1-6
> t/pmc/scratchpad.t 3 768 3 3 100.00% 1-3
make realclean or even distclean should help for those.
leo
Simon Glover
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.
Simon
Andy Dougherty
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 doug...@lafayette.edu
Blair Christensen
> ### frivolous (Solaris 9 on Sparc; gcc-3.1) ###
>
> Looks like it crashed in the hashtable test. Why???
>
> Failed Test Stat Wstat Total Fail Failed List of Failed
> --------------------------------------------------------------
> t/pmc/perlhash.t 1 256 21 1 4.76% 17
This is odd. When I run 'make test', the perlash 'Testing clone' test
fails. However, when I run 'perl -Ilib t/pmc/perlhash.t', all of the
tests report as passed. I don't have time to examine this more closely
right now (as I've got a flight to catch), but next week, once work is
less hectic and I'm back in the office, I'll look at this again.
In addition, I'll be installing the latest Sun Workshop Pro compiler on
frivolous and running that as another tinderbox client once I've talked
to our licensing office.
Of course, it would also be nice if I could convince parrot not to dump
core on a regular basis on my other tinderbox client (drinky-drinky
(OpenBD 3.1 + gcc 2.95.3)), but there are only so much free time...
blair.
Andy Dougherty
> On Tue, Nov 19, 2002 at 09:33:10PM -0800, Steve Fink wrote:
> > ### frivolous (Solaris 9 on Sparc; gcc-3.1) ###
> >
> > Looks like it crashed in the hashtable test. Why???
> >
> > Failed Test Stat Wstat Total Fail Failed List of Failed
> > --------------------------------------------------------------
> > t/pmc/perlhash.t 1 256 21 1 4.76% 17
>
> This is odd. When I run 'make test', the perlash 'Testing clone' test
> fails. However, when I run 'perl -Ilib t/pmc/perlhash.t', all of the
> tests report as passed.
'make test' runs with the environment variable PARROT_GC_DEBUG set.
It's apparently this that causes the tests to fail.
--
Andy Dougherty doug...@lafayette.edu
Leopold Toetsch
> 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.
Thanks for tracking it down that far.
Does this patch help:
--- dod.c Wed Nov 6 11:19:32 2002
+++ /home/lt/src/parrot-leo/dod.c Thu Nov 21 08:29:08 2002
@@ -66,6 +66,14 @@
struct Stash *stash;
UINTVAL mask = PMC_is_PMC_ptr_FLAG | PMC_is_buffer_ptr_FLAG
| PMC_custom_mark_FLAG;
+#ifdef HAS_HEADER_SETJMP
+ jmp_buf env;
+
+ /* this should put registers in env, which then get marked in
+ * trace_system_stack below
+ */
+ setjmp(env);
+#endif
leo
Jason Gloudon
My patch in 16237 has the code to flush register windows on v8 and older and v9
(64-bit) SPARC systems, which is what one is really trying to achieve via
setjmp.
--
Jason
Andy Dougherty
Alas, no, though it seems to me you may be on the right track. What
appears to be happening is that sub.c is getting lex->names from list_new,
but (when compiled with optimization) list_new is returning a list that is
not on the stack. Indeed, if I try to use the debugger and "print list"
while in list_new, I simply get
(dbx) print list
list = (nil)
The smallest change I have found to make it work is to add the single
line fiddle(&list) to the end of list_new (where fiddle is a do-nothing
function hidden away in another file so that the compiler can't
optimize it away). This, however, adds the requirement that the
compiler put list somewhere where it can validly take its address, and
t/op/lexicals_1.pbc works again. (I haven't checked yet whether all
the other tests also succeed. I suspect not, however since I think you
are right that the stack-walking is the problem. list.c:list_new looks
fine -- it just happens to be the first file I found where the
optimizer made a difference.
--
Andy Dougherty doug...@lafayette.edu
Dan Sugalski
If this hasn't been applied, could someone with a Sparc apply it
locally to make sure it fixes the problem? If so, lets get it applied.
Jason Gloudon
On Thu, Nov 21, 2002 at 10:28:42AM -0500, Andy Dougherty wrote:
> > +#ifdef HAS_HEADER_SETJMP
> > + jmp_buf env;
> > +
> > + /* this should put registers in env, which then get marked in
> > + * trace_system_stack below
> > + */
> > + setjmp(env);
> > +#endif
>
> Alas, no, though it seems to me you may be on the right track. What
> appears to be happening is that sub.c is getting lex->names from list_new,
> but (when compiled with optimization) list_new is returning a list that is
> not on the stack. Indeed, if I try to use the debugger and "print list"
> while in list_new, I simply get
After a bit of research on google I found that setjmp on SPARC only saves the
stack pointer, the frame pointer and the program counter, which is why the
setjmp technique does not work. longjmp() on the other hand does do a window
flush in order to unroll stack frames.
--
Jason
Andy Dougherty
> At 9:53 AM -0500 11/21/02, Jason Gloudon wrote:
> >On Thu, Nov 21, 2002 at 08:34:04AM +0100, Leopold Toetsch wrote:
> >
> >My patch in 16237 has the code to flush register windows on v8 and
> >older and v9
> >(64-bit) SPARC systems, which is what one is really trying to achieve via
> >setjmp.
>
> If this hasn't been applied, could someone with a Sparc apply it
> locally to make sure it fixes the problem? If so, lets get it applied.
Alas, it doesn't appear to do the trick. (Or it might have done something
but something else could still be amiss.) I still get pretty much the
same core dump.
While compiling, I did get the warnings:
"cpu_dep.c", line 24: warning: initializer does not fit or is out of
range: 0x91d02003
"cpu_dep.c", line 26: warning: initializer does not fit or is out of
range: 0x81c3e008
Perhaps that's a problem?
Alas I'm out of time to do anything about this. I wonder if perhaps the
main parrot Makefile should turn off -g and leave in the default
optimization that it picks up from perl5? Then at least others could join
in the chase :-).
--
Andy Dougherty doug...@lafayette.edu
Jason Gloudon
> While compiling, I did get the warnings:
>
> "cpu_dep.c", line 24: warning: initializer does not fit or is out of
> range: 0x91d02003
> "cpu_dep.c", line 26: warning: initializer does not fit or is out of
> range: 0x81c3e008
That in itself shouldn't have mattered (signed/unsigned) but this version does
fix the lexicals.t test failures.
--
Jason
Leopold Toetsch
gcc 2.95.2, everything compiled -g -O3 (except core_cg)
Failed Test Status Wstat Total Fail Failed List of failed
-------------------------------------------------------------------------------
t/op/lexicals.t 6 1 16,67% 3
With my patch all tests succeed. So we definitely need to check
processor registers for PMC/Buffers.
If setjmp does save all the registers as i386/gcc does, the setjmp is
enough. For other architectures/compilers we need some assembler code,
to put all processor registers in Parrot_jump_buff. A look at the
sources of gcc/config/* or ruby shows how to do it ;-)
Also instead of set_jmp, we need Parrot_set_jmp, which saves registers.
> Simon
leo