pcc_reapply branch: segfault in t/op/gc.t from r41680
Jonathan Leto
jaleto at gmail.com
Tue Oct 6 23:01:15 UTC 2009
Howdy,
This could be related, maybe not.
With the default compile options on FreeBSD 6.2, the pcc_reapply
branch goes into an infinite loop for me in t/pmc/namespace-old.t .
If you have some tuits, please throw some my way.
Duke
On Tue, Oct 6, 2009 at 4:40 AM, James E Keenan <jkeen at verizon.net> wrote:
> 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
>
--
Jonathan Leto
jonathan at leto.net
http://leto.net
More information about the parrot-dev
mailing list