Ticket #1067 (closed bug: fixed)

Opened 5 years ago

Last modified 4 years ago

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

Reported by: jkeenan Owned by: jkeenan
Priority: normal Milestone:
Component: GC Version: 1.6.0
Severity: medium Keywords: pmc GC
Cc: bacek, whiteknight, fperrad Language:
Patch status: applied Platform:

Description

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

Attachments

t.pmc.objects.t.bt.txt Download (4.6 KB) - added by jkeenan 5 years ago.
backtrace, as requested by NotFound
41448.41449.diff Download (9.5 KB) - added by jkeenan 5 years ago.

Change History

in reply to: ↑ description ; follow-up: ↓ 3   Changed 5 years ago by 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.

in reply to: ↑ description   Changed 5 years ago by 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));
    }
}

Changed 5 years ago by jkeenan

backtrace, as requested by NotFound

in reply to: ↑ 1   Changed 5 years ago by 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.

follow-up: ↓ 5   Changed 5 years ago by jkeenan

  • cc bacek added

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.

Changed 5 years ago by jkeenan

in reply to: ↑ 4   Changed 5 years ago by 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.

  Changed 5 years ago by 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

follow-up: ↓ 8   Changed 5 years ago by 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

in reply to: ↑ 7   Changed 5 years ago by jkeenan

  • status changed from new to assigned
  • owner set to jkeenan
  • patch set to applied

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

follow-up: ↓ 10   Changed 5 years ago by 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

in reply to: ↑ 9 ; follow-up: ↓ 11   Changed 5 years ago by 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.

in reply to: ↑ 10   Changed 5 years ago by bacek

  • owner changed from jkeenan to whiteknight
  • status changed from assigned to new

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

  Changed 5 years ago by 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).

follow-up: ↓ 14   Changed 5 years ago by 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)

in reply to: ↑ 13 ; follow-up: ↓ 17   Changed 5 years ago by 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.

  Changed 5 years ago by jkeenan

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

  Changed 5 years ago by whiteknight

  • owner whiteknight deleted

in reply to: ↑ 14   Changed 5 years ago by 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

follow-up: ↓ 19   Changed 4 years ago by jkeenan

  • owner set to jkeenan
  • status changed from new to assigned
  • cc whiteknight, fperrad added

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

in reply to: ↑ 18   Changed 4 years ago by jkeenan

  • status changed from assigned to closed
  • resolution set to fixed

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

Note: See TracTickets for help on using tickets.