Closed Bug 1292852 Opened 9 years ago Closed 8 years ago

Intermittent test_bug399925.html,test_fileapi_slice.html (and many more) | application crashed [@ js::CompartmentChecker::check] after Assertion failure: IsInsideNursery(obj) || !obj->asTenured().isMarked(gc::GRAY)

Categories

(Core :: JavaScript: GC, defect, P3)

Product:
Core
Component:
JavaScript: GC
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox50 --- wontfix
firefox51 --- wontfix
firefox52 --- wontfix
firefox-esr52 --- fixed
firefox53 --- fixed
firefox54 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: terrence)

References

Details

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

Attachments

(1 file)

add_barrier_on_wrapper_target-v0.diff
1.22 KB, patch
Details | Diff | Splinter Review
Summary: Intermittent image/test/mochitest/test_bug399925.html | application crashed [@ js::CompartmentChecker::check] after Assertion failure: IsInsideNursery(obj) || !obj->asTenured().isMarked(gc::GRAY) → Intermittent test_bug399925.html (and many more) | application crashed [@ js::CompartmentChecker::check] after Assertion failure: IsInsideNursery(obj) || !obj->asTenured().isMarked(gc::GRAY)
Another gray marking intermittent failure, in case you missed it Terrence.
Flags: needinfo?(terrence)
Hey, this one may actually be actionable! Something is calling Object.toSource. Part of toSource needs the className of the source object. This calls GetObjectClassName, which calls Proxy::className, which dispatches to XRawWrapper::className, which calls CrossCompartmentWrapperMap::className. We now have the object we initially called GetObjectClassName on, but as Wrapper; presumably this object is already black as it has been ingressed and is being processed by JSAPI. To get the actual class name, we enter the compartment of the wrapper target and call GetObjectClassName again, now on the wrappee. GetObjectClassName asserts that cx is same compartment with obj, presumably because of it's direct use in this call chain. This finds that wrappee is gray, a state that is allowed, as it is in the wrapper map. So naively, we'd just want to ExposeToActiveJS on the target and move on, but I'm not sure it's that simple. GetObjectClassName only does obj->getClass()->name; looking at the code, it should not be possible to trigger GC between when we pull the wrappee out of the wrapper and when it gets returned. So it seems like maybe exposing in this case would actually be excessive and potentially prevent collection of a thing that is dead. Or maybe not. If we're getting the className of the wrapper, that means there's an active reference in the system. My feeling is that if we don't Expose here we'll end up finding it as a black->gray edge when GC happens later and have to trigger an even worse code path. Following that logic, I see that everything in this block (isArray, hasInstance, hasOwn, etc) have the same bug as target is not read-barriered. I think we may want a full read barrier on ->target here just to be sure. Assuming that doesn't cause us to just leak the world or something.
Flags: needinfo?(terrence)
This is the patch I'm trying. I'm cautiously optimistic.
Assignee: nobody → terrence
Status: NEW → ASSIGNED
Summary: Intermittent test_bug399925.html (and many more) | application crashed [@ js::CompartmentChecker::check] after Assertion failure: IsInsideNursery(obj) || !obj->asTenured().isMarked(gc::GRAY) → Intermittent test_bug399925.html,test_fileapi_slice.html (and many more) | application crashed [@ js::CompartmentChecker::check] after Assertion failure: IsInsideNursery(obj) || !obj->asTenured().isMarked(gc::GRAY)
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
This was not fixed by bug 1296275. I looked at a few logs, and each had a different stack. One was in xpc::XrayTraits::getExpandoObjectInternal, one was in js::CallJSNative, and the third was in nsJSUtils::ModuleEvaluation.
See Also: 1296275 → 1298773
See Also: → 1302274
Any news/updates here, Jon? :)
Flags: needinfo?(jcoppeard)
Blocks: 1317672
> I looked at a few logs, and each had a different stack. One was in xpc::XrayTraits::getExpandoObjectInternal I just filed bug 1322539 on that one. It wouldn't have been fixed by the patch in this bug.
Oddly enough, this has spiked on Linux32 debug since Fx52 was uplifted to Beta on Monday. Though I guess that's bug 1322539. https://treeherder.mozilla.org/logviewer.html#?job_id=71802784&repo=mozilla-beta
See Also: → 1336630
bug 1336630 recently spiked this week (44 failures in the last 7 days)
Status update: I'm working on these gray marking assertion failures but don't have a fix yet. Please see the bugs I've filed under bug 1317672.
Whiteboard: [stockwell needswork]
there are no instances of this bug since Feb 9th- i think this is fixed.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Flags: needinfo?(jcoppeard)
Resolution: --- → FIXED
Whiteboard: [stockwell needswork] → [stockwell fixed]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: