On Solaris/SPARC, I'm still seeing failure on the tests others have
reported problems for.
Failed 3/133 test scripts, 97.74% okay. 30/2167 subtests failed, 98.62%
okay.
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/dynclass/pybuiltin.t 3 768 6 3 50.00% 2 4-5
t/dynclass/pyclass.t 3 768 6 3 50.00% 2 5-6
t/dynclass/pyint.t 24 6144 25 24 96.00% 1-10 12-25
7 tests and 66 subtests skipped.
GNUmake: *** [test] Error 11
$ cat ./.timestamp
1107532815
Fri Feb 4 16:00:15 2005 UTC
(time of this cvs update)
The failures leave a core dump with a backtrace that looks something like:
[EMAIL PROTECTED] ([EMAIL PROTECTED]) terminated by signal SEGV (no mapping at
the fault address)
(dbx) where
current thread: [EMAIL PROTECTED]
=>[1] Parrot_switch_to_cs(0x3a4b38, 0x9de3bf98, 0x1, 0x3d2f70, 0x188,
0x3d2f78), at 0x6f740
[2] Parrot_Sub_invoke(0x3a4b38, 0x3e0d20, 0x0, 0xff141ce4, 0x0, 0x0), at
0x1c6dfc
[3] Parrot_Closure_invoke(0x3a4b38, 0x3e0d20, 0x0, 0x0, 0x0, 0x0), at 0x1c76bc
[4] Parrot_PyFunc_invoke(0x3a4b38, 0x3e0d20, 0x0, 0x4, 0x68, 0xffbef530), at
0xff057054
[5] Parrot_PyClass_runops_fromc(0x3a4b38, 0x3e0d20, 0x3ce300, 0x0, 0x0, 0x0),
at 0xff04d898
[6] Parrot_PyClass_call_meth_fromc_P_P(0x3a4b38, 0x3dfb68, 0x3ce300,
0x3df700, 0x0, 0x0), at 0xff04dd14
[7] Parrot_PyObject_find_method(0x3a4b38, 0x3df700, 0x3d0b20, 0x0, 0x0, 0x0),
at 0xff04f128
[8] Parrot_callmethodcc_sc(0x652468, 0x3a4b38, 0x0, 0x0, 0x0, 0x0), at 0xcd59c
[9] runops_slow_core(0x3a4b38, 0x6523a0, 0x0, 0x0, 0x0, 0x0), at 0x17108c
[10] runops_int(0x3a4b38, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x16d630
[11] runops(0x3a4b38, 0x0, 0xffbef98c, 0x0, 0x0, 0x0), at 0x16f344
[12] Parrot_runcode(0x3a4b38, 0x1, 0xffbef98c, 0x0, 0x0, 0x0), at 0xa2f58
[13] Parrot_runcode(0x3a4b38, 0x1, 0xffbef98c, 0x16, 0x23, 0xa), at 0xa2c70
I realize that's not much help -- I'll have to go back and recompile
with debugging symbols -- but since this build took 1.5 hours to
complete (the machine is busy with other tasks), I won't have
anything else to report before next week.
However, I believe that it's the new_cs structure that's not fully
initialized, and that the access violation occurs at line 2136 in
src/packfile.c:
if (new_cs->base.pf != interpreter->code)
interpreter->code = new_cs->base.pf;
--
Andy Dougherty [EMAIL PROTECTED]
