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 <[email protected]> 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 [email protected] http://leto.net _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
