Closed Bug 1336630 Opened 7 years ago Closed 7 years ago

Intermittent dom/promise/tests/test_promise.html | application crashed [@ js::CompartmentChecker::check] after Assertion failure: IsInsideNursery(obj) || !obj->asTenured().isMarked(gc::GRAY), at /home/worker/workspace/build/src/js/src/jscntxtinlines.h:71

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: intermittent-bug-filer, Unassigned)

References

Details

(Keywords: intermittent-failure, Whiteboard: [stockwell fixed]) 

it looks like there is a lot of action in bug 1292852, possibly we wait until that bug is resolved before looking more into this?

this is happening right after:  dom/promise/tests/test_promise.html

I also did some retriggers that might help point out if a specific patch triggered this:
https://treeherder.mozilla.org/#/jobs?repo=autoland&filter-searchStr=debug%20mochitest-5%20linux&tochange=711aa14e4c4cfe5a39fd3c06ac67c4bb31573375&fromchange=f49a72bc7aed912d7cbb546ac5bab19f46b38969&selectedJob=74396057
ok, the main tracking bug is bug 1317672.
waiting on action in bug 1317672
Whiteboard: [stockwell needswork]
I've run this test (and dom/promise/tests) locally 1000 times in a loop and haven't seen any failures.
this fails on linux32/64 debug, specifically in e10s.  Are you running that config?
(In reply to Joel Maher ( :jmaher) from comment #20)
Yes, linux64 optdebug build with e10s.
bummer, similar rates of failure on 12.04 vs 16.04;

:jonco, possibly you could reproduce/debug using a 1 click loaner.
the question is why does this specific test dom/promise/tests/test_promise.html cause the gc:GRAY assertion?  

With the troubles to reproduce this locally, I am planning on disabling this one specific test for linux/debug later this week.
(In reply to Joel Maher ( :jmaher) from comment #25)
> the question is why does this specific test
> dom/promise/tests/test_promise.html cause the gc:GRAY assertion?  

I've had a look at the promises implementation and couldn't find anything wrong with it that would cause this.  What's probably happening is that the gray marking state for some object is wrong and we're only finding out when it's touched by the promises code at a later time.

Problems like this can be sensitive and non-deterministic, for example depending on the timing incremental GC slices.

> With the troubles to reproduce this locally, I am planning on disabling this
> one specific test for linux/debug later this week.

Could you leave it enabled at least until mid-next week?  I've got a couple more patches to land that may affect things, and we won't know whether it's fixed if the test is disabled.
yeah, I can do that.  Would it help to reduce the test case to what is causing the assertions?  I could push a series of them to try to help out- not sure if that would help, but happy to do it.
this looks to be fixed around March 5th :)
Whiteboard: [stockwell needswork] → [stockwell fixed]
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Bug 1342181 would be believable I'd think.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.