Still failing some dynclass/py*.t tests
Andy Dougherty
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:
t@1 (l@1) terminated by signal SEGV (no mapping at the fault address)
(dbx) where
current thread: t@1
=>[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 doug...@lafayette.edu
Andy Dougherty
> 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.
Here are some more details:
t@1 (l@1) signal SEGV (no mapping at the fault address) in
Parrot_switch_to_cs at line 2136 in file "packfile.c"
2136 if (new_cs->base.pf != interpreter->code)
(dbx) where
current thread: t@1
=>[1] Parrot_switch_to_cs(interpreter = 0x5800d0, new_cs = 0x9de3bf70, really = 1), line 2136 in "packfile.c"
[2] Parrot_Sub_invoke(interpreter = 0x5800d0, pmc = 0x78daa0, next = 0x864dc0), line 240 in "sub.c"
[3] Parrot_Closure_invoke(interpreter = 0x5800d0, pmc = 0x78daa0, next = 0x864dc0), line 84 in "closure.c"
[4] Parrot_PyFunc_invoke(interpreter = 0x5800d0, pmc = 0x78daa0, next = 0x864dc0), line 171 in "pyfunc.pmc"
[5] Parrot_invoke(cur_opcode = 0x864dbc, interpreter = 0x5800d0), line 421 in "core.ops"
[6] runops_slow_core(interpreter = 0x5800d0, pc = 0x864dbc), line 147 in "runops_cores.c"
[7] runops_int(interpreter = 0x5800d0, offset = 0), line 742 in "interpreter.c"
[8] runops(interpreter = 0x5800d0, offs = 0), line 81 in "inter_run.c"
[9] Parrot_runcode(interpreter = 0x5800d0, argc = 1, argv = 0xffbefa90), line 768 in "embed.c"
[10] Parrot_runcode(interpreter = 0x5800d0, argc = 1, argv = 0xffbefa90), line 700 in "embed.c"
[11] main(argc = 1, argv = 0xffbefa90), line 603 in "main.c"
The new_cs structure is coming from Parrot_Sub_invoke in the file sub.c.
It's generated with line 232:
232 struct Parrot_sub * sub = PMC_sub(pmc);
At this point, the 'sub' structure doesn't appear to have anything useful.
(dbx) print *sub
*sub = {
seg = 0x9de3bf70
address = 0xf227a048
end = 0xf027a044
name = 0xe007a044
packed = 0x90140000 "<bad address 0x90140000>"
use_reg_offs = 1080280737U
pad_stack = 0x1000000
}
Attempts to access any of those members yield error messages, like
(dbx) print *sub->name
dbx: cannot access address 0xe007a044
Tracing back further, I lost track and couldn't figure out who was
ultimately responsible for ensuring that 'pmc' was properly initialized,
so I got stuck here.
--
Andy Dougherty doug...@lafayette.edu
Leopold Toetsch
> On Fri, 4 Feb 2005, Andy Dougherty wrote:
>> 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.
> Here are some more details:
> t@1 (l@1) signal SEGV (no mapping at the fault address) in
> Parrot_switch_to_cs at line 2136 in file "packfile.c"
> 2136 if (new_cs->base.pf != interpreter->code)
From which of the failing tests is this traceback? "parrot -t" should
also reveal the failing function call.
leo
Andy Dougherty
Most (if not all) of the tests failed at the same spot. (I didn't check
every one, but every one I did check failed at the same spot.)
The parrot -t output for the two typical cases I have identified
so far follows:
$ ./parrot -t t/dynclass/pybuiltin_2.imc
0 new_pad 0
2 loadlib P17, "python_group" - P17=PMCNULL,
5 find_global P0, "PyBuiltin", "__load__" - P0=PMCNULL, ,
9 invoke
Segmentation Fault(coredump)
$ ./parrot -t t/dynclass/pyint_25.imc
0 loadlib P1, "python_group" - P1=RetContinuation=PMC(0x78fca0 Adr:0x0),
3 find_type I30, "PyInt" - I30=0,
6 new P18, I30 - P18=PMCNULL, I30=85
9 new P17, I30 - P17=PMCNULL, I30=85
12 set P18, 31 - P18=PyInt=PMC(0x78c5e0),
15 set P17, -13 - P17=PyInt=PMC(0x78c5c8),
18 new P16, I30 - P16=PMCNULL, I30=85
21 bxor P16, P18, P17 - P16=PyInt=PMC(0x78c5b0), P18=PyInt=PMC(0x78c5e0), P17=PyInt=PMC(0x78c5c8)
25 print P16 - P16=PyInt=PMC(0x78c5b0)
27 print " "
29 set P5, P17 - P5=SArray=PMC(0x78fcb8), P17=PyInt=PMC(0x78c5c8)
32 set I0, 1 - I0=0,
35 set I1, 0 - I1=0,
38 set I2, 0 - I2=0,
41 set I3, 1 - I3=1,
44 set I4, 0 - I4=0,
47 set P2, P18 - P2=PMCNULL, P18=PyInt=PMC(0x78c5e0)
50 callmethodcc "__xor__"
# find_method class 'PyInt' method '__xor__': no
# find_method class 'PyInt' method '__xor__': Sub
# find_method class 'PyNCI' method '__get__': no
# find_method class 'PyNCI' method '__get__': Sub
# Invoking __get__ on PyNCI
Segmentation Fault(coredump)
--
Andy Dougherty doug...@lafayette.edu