This bug was filed from the Socorro interface and is report bp-67b99a72-992d-4afb-9272-d8a430171016. ============================================================= Crashing Thread (0) Frame Module Signature Source 0 xul.dll js::InterpreterFrame::callee() js/src/vm/Stack.h:649 1 xul.dll js::InterpreterFrame::prologue(JSContext*) js/src/vm/Stack.cpp:244 2 xul.dll js::InterpreterStack::pushExecuteFrame(JSContext*, JS::Handle<JSScript*>, JS::Value const&, JS::Handle<JSObject*>, js::AbstractFramePtr) js/src/vm/Stack.cpp:485 3 xul.dll js::MovableCellHasher<JSObject*>::match(JSObject* const&, JSObject* const&) js/src/gc/Barrier.cpp:195 this crash signature is visibly rising in 57.0b since beta 7 on 32bit builds on windows. bugs fixed in 57.0b7: https://mzl.la/2fY89Dn

Hey Naveed, can your team help triage this?

65% of crashes with the InterpreterFrame::callee() signature have the stack above. This stack is not possible: MovableCellHasher<JSObject*>::match() calls into Zone methods but never into InterpreterStack.

Spike in crashes lately; of the crashes this week most have 0xfff* addressed, but 2 have e5e5 addresses. 0xffff* addresses can also apparently mean that crashreporter can't determine the actual crash address. Line # and stacks for the e5 crashes and the ff crashes are the same. See https://crash-stats.mozilla.com/report/index/72fbf6db-ce51-4018-9091-d8b280171028

Note that this is when executing JSM code AFAICS, and so is bug 1384544, so this *could* be related to XDR corruption like bug 1407651. There seems to be a cluster of similar bugs :/ In any case, the bug here is not in or anywhere near InterpreterFrame::callee.

Note that some of the stacks here suggest we're pushing an *execute* frame, not a *call* frame. Then in InterpreterFrame::prologue we somehow think we have a function/call frame and call frame->callee(), and that's bad of course. Now, InterpreterFrame::callee basically does frame->argv_[-2]. What is argv_ for execute frames? Unfortunately it's initialized only for call frames so it can be anything. Let's say argv_ is 0, then argv_[-2] = 0xfffffff0 -> many crashes have this address. Let's say argv_ is 0xe5e5e5e5, then argv[-2] = 0xe5e5e5d5 -> explains the crash address in comment 3. The question then is, why do we get confused about the type of frame we pushed? The answer is most likely that our JSScript or its body scope is corrupt, since that determines the script type. Since this is highly intermittent, it suggests XDR corruption, uninitialized memory, or something.

Tracking for 57 in case this is something we'll want to uplift for 57 release.

This is very similar to bug 1384544.

Adding to my XDR crash collection...

This problem does not occur in FF58, but is very very similar to 1415748. Closing as fixed by Bug 1418894.