507685 - Intermittent assertion happening in as3/sampling/Callback.as

Status: VERIFIED WORKSFORME

(Tamarin Graveyard :: Garbage Collection (mmGC), defect, P4)

Description

[Brent Baker]

We have been seeing an intermittent assertion happening in the as3/sampling/Callback.as on windows64, mac-intel-10.5 and solaris.

as3/sampling/Callback.abc : Assertion failed: "(((start_event == (PolicyEvent)(ev - 1))))" (".\\GC.cpp":461)

Disabling test until this is corrected/investigated

Comment 1

[Brent Baker]

Testcase currently being skipped on all platforms:

changeset:   2296:4fcfce54b0f5
tag:         tip
user:        Brent Baker <[e-mail]>
date:        Fri Jul 31 14:59:31 2009 -0400
summary:     Bug 507685: disable as3/sampling/Callback.as until bug is resolved, intermittent assertion is happening at GC.cpp:461

Comment 2

[Steven Johnson]

Do we have any guess as to why its intermittent, and/or what's going on with it?

Comment 3

[Lars T Hansen]

(In reply to comment #2)
> Do we have any guess as to why its intermittent, and/or what's going on with
> it?

No, this is pretty mysterious.  It suggests that there is possibly recursion or reentrancy where we would expect there to be none, since the policy events are supposed to be "flat".  At a guess, if user code is invoked from a GC callback and we haven't taken that into account then this could conceivably happen.

Comment 4

[Steven Johnson]

perhaps we could try running the test in greedy mode...

Comment 5

[Lars T Hansen]

(In reply to comment #3)
> ... At a guess, if user code is invoked from a GC callback
> and we haven't taken that into account then this could conceivably happen.

- The postsweep() callbacks are called when the GC is "finished" (both marking
  and collecting have been set to false) but the END_FinalizeAndSweep signal is
  sent after that.  So if postsweep() causes activity that triggers the start
  of a new GC we should get exactly this assertion when END_FinalizeAndSweep
  is sent.

  However, all postsweep() callbacks in the VM shell appear to be completely
  trivial.

- The prereap() callbacks are called after the START_ReapZCT has been sent,
  but nothing stops the prereap() callbacks from triggering a GC.  Then the
  assert should be seen when the START_StartIncrementalMark event is sent.

  However, all prereap() callbacks in the VM shell appear to be completely
  trivial.

Comment 6

[Lars T Hansen]

(In reply to comment #5)
> - The prereap() callbacks are called after the START_ReapZCT has been sent,
>   but nothing stops the prereap() callbacks from triggering a GC.  Then the
>   assert should be seen when the START_StartIncrementalMark event is sent.

Actually the assert would be seen when the END_ReapZCT even is signalled, after the signalling of END_StartIncrementalMark has cleared the event history.

Comment 7

[Lars T Hansen]

More user code: C++ destructors are run during ZCT reaping.  The destructors could in principle trigger the start of a GC or force an ongoing GC to completion.  In either case allocation would be required, and there's not a lot of allocation among the destructors in the VM shell.  However not much allocation is needed if the system is on the brink in any case.

Comment 8

[Lars T Hansen]

C++ destructors are also run during sweeping, but at that point the state of the system is such that it should not be possible to trigger a new collection or a zct reap.

I've added some better debugging code to Tamarin and will probably re-enable the test to see if further testing will give us more data.

Comment 9

[Lars T Hansen]

redux changeset: 3003:7c2238cace24 re-enables the test.

Comment 10

[Lars T Hansen]

Two months on we've not seen another instance of this - closing as UTR.