Closed Bug 1299780 Opened 6 years ago Closed 5 years ago
_sanitize Dialog .js | application crashed [@ JSCompartment::wrap(JSContext*, JS::Mutable Handle<JSObject*>, JS::Handle<JSObject*>)] (Assertion failure: !Object Is Marked Gray(obj), at js/src/jscompartment .cpp:372)
Filed by: rvandermeulen [at] mozilla.com https://treeherder.mozilla.org/logviewer.html#?job_id=35108711&repo=mozilla-inbound https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-macosx64-debug/1472724621/mozilla-inbound_yosemite_r7-debug_test-mochitest-e10s-browser-chrome-7-bm106-tests1-macosx-build981.txt.gz
OK, so the relevant part of the stack is this: 1 XUL!JSCompartment::wrap(JSContext*, JS::MutableHandle<JS::Value>) [jscompartmentinlines.h:dedd56fa5c54 : 119 + 0x12] 2 XUL!js::PromiseReactionJob [Promise.cpp:dedd56fa5c54 : 1066 + 0x8] 3 XUL!js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) [jscntxtinlines.h:dedd56fa5c54 : 235 + 0x6] 4 XUL!js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) [Interpreter.cpp:dedd56fa5c54 : 442 + 0xe] 5 XUL!<name omitted> [Interpreter.cpp:dedd56fa5c54 : 518 + 0x8] 6 XUL!JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) [jsapi.cpp:dedd56fa5c54 : 2834 + 0x15] 7 XUL!mozilla::dom::PromiseJobCallback::Call(JSContext*, JS::Handle<JS::Value>, mozilla::ErrorResult&) [PromiseBinding.cpp:dedd56fa5c54 : 62 + 0xb] 8 XUL!mozilla::dom::PromiseJobCallback::Call(mozilla::ErrorResult&, char const*, mozilla::dom::CallbackObject::ExceptionHandling, JSCompartment*) [PromiseBinding.h:dedd56fa5c54 : 176 + 0xb] 9 XUL!PromiseJobRunnable::Run() [PromiseBinding.h:dedd56fa5c54 : 191 + 0x1b] 10 XUL!mozilla::dom::Promise::PerformMicroTaskCheckpoint() [Promise.cpp:dedd56fa5c54 : 1002 + 0x6] I thought we'd fixed this stuff up in promise code one already... Anyway, the call in frame 2 is this: if (!cx->compartment()->wrap(cx, &handlerVal)) where "handlerVal" comes from: RootedValue handlerVal(cx, job->getExtendedSlot(ReactionJobSlot_Handler)); and "job" comes from: RootedFunction job(cx, &args.callee().as<JSFunction>()); None of "job" and "handlerVal" have been unwrapped so far this function, so our function callee is presumably gray. :( What I don't understand, so far, is how this can happen in this setup. We know PromiseJobCallback unmarks everything gray as needed. And after that we're just running self-hosted code... I really wish we had all this stuff under rr. :(
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
Something made this go away around 16-Sep.
Which is conveniently very close to when bug 1294747 landed.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
See Also: 1291776 →
Duplicate of bug: 1294747
That's slightly weird; I don't expect there to be any document.open() in this test and it's not on the stack for the assertion failure... I guess in that bug we were working with possibly-dead objects so to some extent all bets were off, but still.
It's the only plausible-looking fix I can see on inbound around the time it stopped. Unless it was bug 1302523 doing something like we saw over in bug 1293057, which would be unfortunate if true. But that's the only other GC-looking patch I can see around that timeframe.
I can try to bisect the fix if you think it's worth it, though.
If it's not too much trouble, I would appreciate it. I really want to understand what the heck is going on here.
Turns out with enough retriggers, I can hit it on newer pushes than the 16th (even as recent as the 21st), but the frequency is way lower now (I hit it on 1 out of 500 tries on one push). So I guess this really isn't fixed :\
Status: REOPENED → RESOLVED
Closed: 6 years ago → 5 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.