966490 - Crashes in js::ObjectImpl::getClass() under WeakMap::keyNeedsMark with poisoned GC pointer

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Jan de Mooij [:jandem]]

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?

Comment 1

[Andrew McCreight [:mccr8]]

One random guess is that exact rooting is on in 29 but not 28...

Comment 2

[David Bolter [:davidb] (NeedInfo me for attention)]

Terrence, any thoughts on comment 0 or comment 1?

Comment 3

[Terrence Cole [:terrence]]

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?

Comment 4

[Al Billings [:abillings - ex-MoCo]]

Can anyone take this and get 'er done?

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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.

Comment 6

[David Bolter [:davidb] (NeedInfo me for attention)]

Still no stacks in 29+...

Comment 7

[Andrew McCreight [:mccr8]]

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.

Comment 8

[Andrew McCreight [:mccr8]]

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.

Comment 9

[Robert Kaiser]

(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.