#1393: t/compilers/pge/pge_examples.t: PASS by itself, FAIL during 'make smoke'
---------------------+------------------------------------------------------
Reporter: jkeenan | Owner:
Type: bug | Status: new
Priority: major | Milestone:
Component: testing | Version: 1.9.0
Severity: high | Keywords:
Lang: | Patch:
Platform: |
---------------------+------------------------------------------------------
Comment(by lithos):
Replying to [comment:26 whiteknight]:
> I just tried to reproduce this failure on Linux-x64 with no luck. I'm
trying to wade through all the posts above, but I'm not sure I have a
consistent view of the problem. What platforms is this test failing on?
What are the incantations I need to reproduce it?
To summarize my (limited) view of the problem:
RetContinuation wrongly assumes that it knows all pointers to itself
(namely a single one from a context) and puts itself on the free list. If
there are still pointers around to the RetContinuation ''and a GC run is
triggered while these pointers are still live'' the assertion failure
happens when marking the (former) RetContinuation. The emphasized
condition in the previous sentence is the reason IMHO that this bug is so
elusive. For example, it could depend on C compiler optimizations, if a
pointer to a context holding a now-invalid pointer to the RetContinuation
is still on the stack.
bacek's changes in r43414 fixed some, but I think not all cases where
there is another pointer to the RetContinuation.
I think this modification unhides the bug (I'm not sure, however, if it
does not also break valid code):
{{{
Index: src/pmc/retcontinuation.pmc
===================================================================
--- src/pmc/retcontinuation.pmc (revision 43432)
+++ src/pmc/retcontinuation.pmc (working copy)
@@ -86,6 +86,7 @@
if (!PMC_IS_NULL(from_ctx))
Parrot_pcc_set_continuation(interp, from_ctx, NULL);
Parrot_gc_free_pmc_header(interp, SELF);
+ Parrot_gc_mark_and_sweep(interp, GC_trace_stack_FLAG);
if (INTERP->code != seg)
Parrot_switch_to_cs(INTERP, seg, 1);
}}}
An incantation to show the bug with this change is:
{{{
./parrot t/library/test_more.t
}}}
But a simple "make" also does parrot invocations where the bug is
triggered with the above patch applied.
If my assumptions are right, this modification should make the bug
disappear:
{{{
Index: src/pmc/retcontinuation.pmc
===================================================================
--- src/pmc/retcontinuation.pmc (revision 43432)
+++ src/pmc/retcontinuation.pmc (working copy)
@@ -85,7 +85,6 @@ Transfers control to the calling context
/* recycle this PMC and make sure it doesn't get marked */
if (!PMC_IS_NULL(from_ctx))
Parrot_pcc_set_continuation(interp, from_ctx, NULL);
- Parrot_gc_free_pmc_header(interp, SELF);
if (INTERP->code != seg)
Parrot_switch_to_cs(INTERP, seg, 1);
}}}
jkeenan, does the failure you see persist if you apply the second patch?
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/1393#comment:29>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
