Closed Bug 966490 Opened 7 years ago Closed 7 years ago
Crashes in js::Object
Impl::get Class() under Weak Map::key Needs Mark with poisoned GC pointer
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?
One random guess is that exact rooting is on in 29 but not 28...
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?
Can anyone take this and get 'er done?
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.
Still no stacks in 29+...
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: 7 years ago
Resolution: --- → INCOMPLETE
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.
Status: RESOLVED → REOPENED
Crash Signature: [@ js::ObjectImpl::getClass() ]
Resolution: INCOMPLETE → ---
(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.
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.