Closed
Bug 966490
Opened 11 years ago
Closed 11 years ago
Crashes in js::ObjectImpl::getClass() under WeakMap::keyNeedsMark with poisoned GC pointer
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: jandem, Unassigned)
References
Details
(Keywords: csectype-uaf, sec-critical)
Crash Data
I was looking at Aurora crashes for another bug and noticed we have a topcrash there in js::ObjectImpl::getClass() and most of the stacks are like this: - js::ObjectImpl::getClass() - js::WeakMap<js::EncapsulatedPtr..snip..>::keyNeedsMark(JSObject *) - js::WeakMap<js::EncapsulatedPtr<..snip..>::markIteratively(JSTracer *) - MarkWeakReferences<js::CompartmentsIterT<js::gc::GCZoneGroupIter> > See for instance: https://crash-stats.mozilla.com/report/index/38bfc3d3-78f4-4d0f-9a5c-b8f322140129 We crash because we're accessing a bogus pointer: 0xdadadada. I opened a few reports and these also all had IncrementalCollectSlice on the stack. Bill, Terrence: long shot but does anything about WeakMap marking on Aurora stand out to you? This seems to only affect Aurora; maybe a fix for some related bug went into 29?
Updated•11 years ago
|
Keywords: sec-critical
Updated•11 years ago
|
Keywords: csectype-uaf
Comment 2•11 years ago
|
||
Terrence, any thoughts on comment 0 or comment 1?
status-firefox27:
--- → ?
status-firefox28:
--- → affected
status-firefox29:
--- → ?
Flags: needinfo?(terrence)
Comment 3•11 years ago
|
||
Exact rooting doesn't really interact directly with weak marking. It changes the liveness graph, but not in any way that should impact this sort of crash directly. IIRC, we've had a persistent small volume of crashes on dead weakmap keys under various signatures basically forever with seemingly random spikes up and down. A dead key would probably indicate that sweeping the table failed or didn't happen. Maybe Jon or Steve can think of something more relevant here?
Flags: needinfo?(terrence)
Flags: needinfo?(sphink)
Flags: needinfo?(jcoppeard)
I don't think anyone knows what the problem is. It looks like we have a dead weakmap key, but it's not clear why.
Updated•11 years ago
|
Group: javascript-core-security
Comment 7•11 years ago
|
||
This only ever showed up on 29, and I don't even see it there in the top 50 crashes now, so I think there's not much else we can do here. Please reopen if we get more information.
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: needinfo?(sphink)
Flags: needinfo?(jcoppeard)
Resolution: --- → INCOMPLETE
Comment 8•11 years ago
|
||
I'm reopening this because it looks really similar to the crash in bug 984101, which is a 1.3T blocker. 1.3 is based on Firefox 28. There's not a lot to go on here, but maybe we have historical crash stats datae that could provide some information? Kairo, is there some way we could figure out the history of this crash signature on 28 and 29? Like, maybe it went away from the top 50 crashes on some particular day on 28, and on some other day for 29? That might be useful to figure out what if anything resolved this problem.
Blocks: 984101
Status: RESOLVED → REOPENED
Crash Signature: [@ js::ObjectImpl::getClass() ]
Flags: needinfo?(kairo)
Resolution: INCOMPLETE → ---
Comment 9•11 years ago
|
||
(In reply to Andrew McCreight [:mccr8] from comment #8) > Kairo, is there some way we could figure out the history of this crash > signature on 28 and 29? Unfortunately I do not have an easy way to do that at this time.
Flags: needinfo?(kairo)
Updated•11 years ago
|
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → INCOMPLETE
Updated•10 years ago
|
Group: javascript-core-security
Updated•9 years ago
|
Group: core-security → core-security-release
Updated•8 years ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•