1350248 - Intermittent browser_cancelCompatCheck.js | application crashed [@ js::Wrapper::wrappedObject(JSObject*)] after Assertion failure: JS::ObjectIsNotGray(target), at Wrapper.cpp:332

Status: RESOLVED DUPLICATE of bug 1350168

(Core :: JavaScript Engine, defect)

Description

[Treeherder Bug Filer]

Filed by: cbook [at] mozilla.com

https://treeherder.mozilla.org/logviewer.html#?job_id=86144075&repo=mozilla-inbound

https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-macosx64-debug/mozilla-inbound_yosemite_r7-debug_test-mochitest-e10s-browser-chrome-4-bm132-tests1-macosx-build179.txt.gz

Comment 1

[Carsten Book [:Tomcat]]

Attachment: crash stack

Comment 2

[Boris Zbarsky [:bzbarsky]]

CheckedUnwrap calls UnwrapOneChecked, which calls Wrapper::wrappedObject.  This asserts that the wrapper target is not gray.

We used to actually mark the target as not gray in this case, until bug 1349637 removed that and replaced it with the assert.  But I don't see why we can assert this.

The comments in bug 1349637 talk about us marking the target black when the wrapper is marked black, which is fine and all, but not enough to ensure the target is non-gray.  In particular, I expect we can have a white wrapper and gray target, if we started a GC in the zone of the wrapper (but not the target) and just haven't gotten to marking the wrapper black yet, right?

We could loosen the assertion to assert that either the target is not gray or we're not black, I suppose...  But either way the gray thing has escaped and who knows who will be pointing to it now.  Seems bad to me.

Comment 4

[Intermittent Failures Robot]

5 failures in 898 pushes (0.006 failures/push) were associated with this bug in the last 7 days.   

Repository breakdown:
* autoland: 3
* mozilla-inbound: 2

Platform breakdown:
* osx-10-10: 5

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1350248&startday=2017-03-20&endday=2017-03-26&tree=all

Comment 5

[Jon Coppeard (:jonco)]

(In reply to Boris Zbarsky [:bz] (still a bit busy) (if a patch has no decent message, automatic r-) from comment #2)
> In particular, I expect we can have a white wrapper and
> gray target, if we started a GC in the zone of the wrapper (but not the
> target) and just haven't gotten to marking the wrapper black yet, right?

This is a really good point.

It seems that this expose call in wrappedObject is there to make our assertions pass until marking catches up and marks the target black.  The thing that concerns me is that this might mask problems where we have missed a barrier earlier on and the target would not have ended up black had we not happened to look through this wrapper.  But we have the heap walk to check the gray marking state before CC now so that should catch problems.

I'll back out bug 1349637.

Comment 6

[Boris Zbarsky [:bzbarsky]]

We could add an assertion that the target is only gray if we're white, to help mitigate things a bit, perhaps?