Closed Bug 1409179 Opened 4 years ago Closed 4 years ago

Crash in js::InterpreterFrame::callee


(Core :: JavaScript Engine, defect, P1)

57 Branch



Tracking Status
firefox-esr52 --- unaffected
firefox57 + wontfix
firefox58 + fixed
firefox59 --- fixed


(Reporter: philipp, Assigned: tcampbell)



(4 keywords, Whiteboard: [adv-main58+][post-critsmash-triage])

Crash Data

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:
Hey Naveed, can your team help triage this?
Flags: needinfo?(nihsanullah)
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.
Flags: needinfo?(jdemooij)
Priority: -- → P1
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.

Group: core-security
Flags: needinfo?(jcoppeard)
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.
Group: core-security → javascript-core-security
This is very similar to bug 1384544.
Flags: needinfo?(jdemooij)
Adding to my XDR crash collection...
Assignee: nobody → tcampbell
Depends on: 1418894
Flags: needinfo?(nihsanullah)
Flags: needinfo?(jcoppeard)
This problem does not occur in FF58, but is very very similar to 1415748. Closing as fixed by Bug 1418894.
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Group: javascript-core-security → core-security-release
Whiteboard: [adv-main58+]
Flags: qe-verify-
Whiteboard: [adv-main58+] → [adv-main58+][post-critsmash-triage]
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.