t/pmc/objects.t: premature death on Darwin/PPC

[jkeenan]

At r41500, I observed a failure in make test in t/pmc/objects.t on Darwin/PPC, but not on Linux i386. Here is the output of prove:

$ prove -v t/pmc/objects.t 
t/pmc/objects.t .. 
1..194
ok 1 - got classname Foo5
ok 2 - got subclass Bar5
[snip]
ok 111 - set/get_integer overridden
ok 112 - set/get_string overridden
src/gc/api.c:253: failed assertion 'PObj_is_PMC_TEST(obj)'
Failed 82/194 subtests 

Test Summary Report
-------------------
t/pmc/objects.t (Wstat: 6 Tests: 112 Failed: 0)
  Non-zero wait status: 6
  Parse errors: Bad plan.  You planned 194 tests but ran 112.
Files=1, Tests=112,  2 wallclock secs ( 0.21 usr  0.04 sys +  0.30 cusr  0.06 csys =  0.61 CPU)
Result: FAIL

Given the name of the C-source code file at which the death occurred, I'm classifying this under the GC component -- but if someone understands this better, they can change that.

Thank you very much.
kid51

[jkeenan]

Replying to jkeenan:

At r41500, I observed a failure in make test in t/pmc/objects.t on Darwin/PPC, but not on Linux i386. Here is the output of prove:

My last make test on this machine was at r41401, so the problem emerged somewhere between 41402 and 41500.

[jkeenan]

Here is the part of t/pmc/objects.t where the failure is observed:

    937 .namespace []       # Reset to root namespace for next test
    938 
    939 .sub PMC_as_classes__derived_3
    940     .local pmc MyInt10
    941     .local pmc MyInt10_2
    942     get_class $P0, "Integer"
    943 
    944     subclass MyInt10, $P0, "MyInt10"
    945     addattribute MyInt10, 'intval'
    946     get_class $P1, "MyInt10"
    947     subclass MyInt10_2, $P1, "MyInt10_2"
    948 
    949     .local pmc i
    950     i = new "MyInt10_2"
    951     $I0 = isa i, "Integer"
    952     ok( $I0, 'obj isa grandparent (Integer)' )
    953     $I0 = isa i, "MyInt10"
    954     ok( $I0, 'obj isa parent (MyInt10)' )
    955     $I0 = isa i, "MyInt10_2"
    956     ok( $I0, 'obj isa its class (MyInt102)' )
    957 
    958     i = 42    # set_integer is overridden below
    959     $I0 = i   # get_integer is overridden below
    960     is( $I0, 42, 'set/get_integer overridden' )
    961 
    962     $S0 = i   # get_string is overridden below
    963     is( $S0, 'MyInt10_2(42)', 'set/get_string overridden' )
    964 .end

Here is the relevant part of src/gc/api.c:

PARROT_EXPORT
void
Parrot_gc_mark_PMC_alive_fun(PARROT_INTERP, ARGMOD_NULLOK(PMC *obj))
{
    ASSERT_ARGS(Parrot_gc_mark_PMC_alive_fun)
    if (!PMC_IS_NULL(obj)) {
        PARROT_ASSERT(PObj_is_PMC_TEST(obj));  ## <-- line 253

        if (PObj_is_live_or_free_TESTALL(obj))
            return;

        /* mark it live */
        PObj_live_SET(obj);

        /* if object is a PMC and contains buffers or PMCs, then attach the PMC
         * to the chained mark list. */
        if (PObj_is_special_PMC_TEST(obj))
            mark_special(interp, obj);
        else if (PMC_metadata(obj))
            Parrot_gc_mark_PMC_alive(interp, PMC_metadata(obj));
    }
}

[jkeenan]

backtrace, as requested by NotFound

[jkeenan]

Replying to jkeenan:

My last make test on this machine was at r41401, so the problem emerged somewhere between 41402 and 41500.

Based on Smolder reports (a) this is PPC-specific; (b) failure occurred between 41448 and 41461. Cf.  this first failing Smolder report at r41461.

[jkeenan]

This failure is appearing in r41449. That means the failure first occurred there or in 41448. Given the files touched in r41449, it is the likely point of failure.

[jkeenan]

Replying to jkeenan:

This failure is appearing in r41449. That means the failure first occurred there or in 41448. Given the files touched in r41449, it is the likely point of failure.

I built and tested r41448; t/pmc/objects.t passed. So r41449 is confirmed as the point of failure.

[bacek]

I can't find anything suspicious in commit by it self. Probably it exposed some brokenes in other part of parrot...

Trying to reproduce now. But I'm on Linux/i386

[bacek]

jkeenan,

can you try this patch?

diff --git a/src/call/context.c b/src/call/context.c
index 54bddee..5aeda57 100644
--- a/src/call/context.c
+++ b/src/call/context.c
@@ -797,6 +797,7 @@ void
 Parrot_pcc_set_results_signature(PARROT_INTERP, ARGIN(PMC *ctx), ARGIN_NULLOK(PMC *sig))
 {
     ASSERT_ARGS(Parrot_pcc_set_results_signature)
+    PARROT_ASSERT(PMC_IS_NULL(sig) || PObj_is_PMC_TEST(sig));
     Parrot_Context *c = get_context_struct_fast(interp, ctx);
     c->results_signature = sig;
 }

According to backtrace fault happens during marking of Context.results_signature, so this one will help to find out where something wrong assigned to this field.

-- Bacek

[jkeenan]

Replying to bacek:

jkeenan, can you try this patch?

bacek,

That worked; thanks for your rapid response!

I applied the patch in r41528. I will take the ticket for the purpose of monitoring Smolder tests over the next several days to ensure that the patch causes no problems elsewhere.

Thank you very much.

kid51

[bacek]

Hang on. Patch shouldn't fix failure. It should just expose where field set to wrong value. If problem is gone it's just hide in different place. I suspect GC on PPC need more write barriers.

-- Bacek

[jkeenan]

Replying to bacek:

Hang on. Patch shouldn't fix failure. It should just expose where field set to wrong value. If problem is gone it's just hide in different place. I suspect GC on PPC need more write barriers.

Well, I can't argue with  tests that once again PASS.

[bacek]

Replying to jkeenan:

Well, I can't argue with  tests that once again PASS.

It is really-really weird. Reassign to Whiteknight to investigate PCC GC.

-- Bacek

[fperrad]

I think this issue is not PPC specific.

Actually, I show this kind of problem with Lua :

 make pmctest

PASS , on Windows.

FAILS, on Xubuntu 9.04 (x86).

[kyle_l5l]

Does this help? It's ugly, but it makes some of my troubles go away.

--- src/gc/api.c	(revision 41542)
+++ src/gc/api.c	(working copy)
@@ -195,9 +195,15 @@
        set of #if preparser conditions. */
 
     /* if object is live or on free list return */
-    if (PObj_is_live_or_free_TESTALL(obj))
-        return;
-
+    if (PObj_is_live_or_free_TESTALL(obj)){
+        if (PObj_is_PMC_TEST(obj)){
+            PMC * const p = (PMC *)obj;
+            if(PMC_metadata(p))
+                Parrot_gc_mark_PObj_alive(interp, (PObj*)PMC_metadata(p));
+        }
+        return;
+    }
+    
 #if ! DISABLE_GC_DEBUG
 #  if GC_VERBOSE
     if (CONSERVATIVE_POINTER_CHASING)

[kyle_l5l]

Replying to kyle_l5l:

Does this help? It's ugly, but it makes some of my troubles go away.

A bit unclear here, sorry. This is just a guess - I'm not seeing trouble with objects.t; however, I have found (unrelated) bugs due to Parrot_gc_mark_PMC_alive_fun() not marking metadata, and this looked familiar.

[jkeenan]

See also TT #1393, where problems with similar parts of src/gc/api.c are also suspected.

[jkeenan]

Replying to kyle_l5l:

Could you do a checkout of the tt1393_retcon branch from SVN and test it?

If that branch works for that TT, I'd like to make sure it, at the very least, does no harm with respect to the problems reported in this ticket.

Thank you very much.

kid51

[jkeenan]

Friends,

The last post in this TT was 4 months ago. kyle_151 never responded. And at some point the tt1393_retcon branch was removed from the repository. t/pmc/objects.t has no todo-ed items and passes for me on darwin/ppc.

So, I'd like to ask the people who posted in this ticket to present any reason why the ticket should remain open. If I hear no objection, I will close it in 3 days max.

Thank you very much.

kid51

[jkeenan]

Replying to jkeenan:

So, I'd like to ask the people who posted in this ticket to present any reason why the ticket should remain open. If I hear no objection, I will close it in 3 days max.

Hearing no complaints, I'm closing this ticket. Thank you very much.

kid51