I followed the progress of hackathon work on the pcc_reapply branch over
the weekend. I was running Smolder tests on the branch on Linux/i386.
At first I was running them as I have done in trunk for more than two
years now:
perl Configure.pl && make && make smolder_test
I was then advised that given the overhaul of Parrot calling conventions
which was the focus of that branch, many tests of things built on top of
the Parrot core would necessarily fail, and that it would be better for
me to simply call this:
perl Configure.pl && make corevm and make coretest
I switched to that (or, more precisely, to 'make smolder_coretest',
which I revised to accomplish the same as above).
Everything was smoldering fine up through r41777, where I broke for the
night. But when I came back the next day and 'svn up', I found that
'make smolder_coretest' would no longer complete. Instead, it would
hang on: t/op/gc.t. I would get as far as test 117 :
ok 117
... and never get to test 118; the screen would simply hang indefinitely.
Curiously, when I would run that test either with 'prove -v' or 't
perl/harness', the harness would complete properly even though the tests
themselves would die:
ok 115 - end vanishing_return_continuation
ok 116
ok 117
Failed 23/140 subtests
Test Summary Report
-------------------
t/op/gc.t (Wstat: 11 Tests: 117 Failed: 0)
Non-zero wait status: 11
Parse errors: Bad plan. You planned 140 tests but ran 117.
Files=1, Tests=117, 1 wallclock secs ( 0.04 usr 0.01 sys + 0.95
cusr 0.09 csys = 1.09 CPU)
Result: FAIL
I was advised by bacek to modify my configuration:
perl Configure.pl --buildframes=0 && make smolder_coretest
Doing so, t/op/gc.t ran without segfaults, passed all its test, and
posed no obstacle to successful completion of tests and submission to
Smolder. It enabled me to resume tracking the progress of the hackathon
and paste reports of failing tests on #parrot.
$ prove -v t/op/gc.t
t/op/gc.t ..
1..140
ok 1 - sweep_1
ok 2 - sweep_0
ok 3 - sweep_0_need_destroy_obj
...
ok 115 - end vanishing_return_continuation
ok 116
ok 117
ok 118 - recursion_and_exceptions
ok 119 - recursion_and_exceptions
ok 120 - leaving write_barrier_1
ok 121 - leaving write_barrier_2
...
ok 140 - done
#
ok
All tests successful.
Files=1, Tests=140, 1 wallclock secs ( 0.02 usr 0.01 sys + 0.56 cusr
0.02 csys = 0.61 CPU)
Result: PASS
This is all well and good, but I'm uncomfortable having to supply a
configuration option I have never needed when testing trunk or any other
branch in order to have a testing target complete. I was the only
person on IRC reporting this problem and I know from experience that
when just one person reports a problem the problem tends to get swept
under the rug. I decided to look more closely. Two approaches yielded data.
1. I bisected and identified r41680 as the revision where t/op/gc.t
first segfaulted at test 118.
ndex: src/pmc/callsignature.pmc
===================================================================
--- src/pmc/callsignature.pmc (revision 41679)
+++ src/pmc/callsignature.pmc (revision 41680)
@@ -229,11 +229,14 @@
VTABLE void mark() {
Parrot_CallSignature_attributes * const attrs =
PARROT_CALLSIGNATURE(SELF);
- if (attrs) {
- Parrot_gc_mark_PMC_alive(interp, attrs->returns);
- Parrot_gc_mark_PMC_alive(interp, attrs->type_tuple);
- Parrot_gc_mark_STRING_alive(interp, attrs->short_sig);
- }
+ if (!attrs)
+ return;
+
+ Parrot_gc_mark_PMC_alive(interp, attrs->returns);
+ Parrot_gc_mark_PMC_alive(interp, attrs->type_tuple);
+ Parrot_gc_mark_STRING_alive(interp, attrs->short_sig);
+ Parrot_gc_mark_PMC_alive(interp, attrs->arg_flags);
+ Parrot_gc_mark_PMC_alive(interp, attrs->return_flags);
SUPER();
}
2. Configuring without --buildframes=0, I built and ran t/op/gc.t
through gdb:
ok 117
[New Thread 0x4113fa40 (LWP 11949)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x4113fa40 (LWP 11949)]
0x400e3557 in Parrot_gc_mark_PMC_alive_fun (interp=0x804f040,
obj=0x418dca3c)
at src/gc/api.c:245
245 {
bt
#0 0x400e3557 in Parrot_gc_mark_PMC_alive_fun (interp=0x804f040,
obj=0x418dca3c) at src/gc/api.c:245
#1 0x40232e19 in Parrot_Context_mark (interp=0x804f040, pmc=0x418dcb04)
at ./src/pmc/context.pmc:63
#2 0x400e59e0 in mark_special (interp=0x804f040, obj=0x418dcb04)
at src/gc/mark_sweep.c:424
#3 0x400e3619 in Parrot_gc_mark_PMC_alive_fun (interp=0x804f040,
obj=0x418dcb04) at src/gc/api.c:259
#4 0x40232e19 in Parrot_Context_mark (interp=0x804f040, pmc=0x418dcbcc)
at ./src/pmc/context.pmc:63
#5 0x400e59e0 in mark_special (interp=0x804f040, obj=0x418dcbcc)
at src/gc/mark_sweep.c:424
#6 0x400e3619 in Parrot_gc_mark_PMC_alive_fun (interp=0x804f040,
obj=0x418dcbcc) at src/gc/api.c:259
#7 0x40232e19 in Parrot_Context_mark (interp=0x804f040, pmc=0x418dcc94)
at ./src/pmc/context.pmc:63
#8 0x400e59e0 in mark_special (interp=0x804f040, obj=0x418dcc94)
at src/gc/mark_sweep.c:424
#9 0x400e3619 in Parrot_gc_mark_PMC_alive_fun (interp=0x804f040,
obj=0x418dcc94) at src/gc/api.c:259
#10 0x40232e19 in Parrot_Context_mark (interp=0x804f040, pmc=0x418dcd5c)
at ./src/pmc/context.pmc:63
#11 0x400e59e0 in mark_special (interp=0x804f040, obj=0x418dcd5c)
... and so on for at least 5000 debugger entries! (This was done at
r41733.)
I think r41680 needs to be re-examined. Moreover, at the point where
the pcc_reapply branch is merged into trunk, you should not have to add
'--buildframes=0' to the configuration call in order to get it to do the
right thing on Linux/i386.
Thank you very much.
kid51
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
