Closed Bug 1425132 Opened 5 years ago Closed 5 years ago

Crash in js::jit::MaybeEnterJit


(Core :: JavaScript Engine: JIT, defect, P3)




Tracking Status
firefox58 --- affected
firefox59 --- affected
firefox60 --- affected


(Reporter: djc, Unassigned)


(Blocks 1 open bug)


(Keywords: crash, nightly-community, topcrash)

Crash Data


(1 file)

This bug was filed from the Socorro interface and is
report bp-65d77646-d658-4a2d-ba3f-c87bc0171213.

Top 10 frames of crashing thread:

0  @0xbffc1360 
1 js::jit::MaybeEnterJit js/src/jit/Jit.cpp:99
2 js::Nursery::allocateObject js/src/gc/Nursery.cpp:277
3 js::LiveSavedFrameCache::~LiveSavedFrameCache js/src/vm/Stack.h
4 js::Allocate<JSObject, js::AllowGC::CanGC> js/src/gc/Allocator.cpp:87
5 js::CallObject::createTemplateObject js/src/gc/Barrier.h:665
6 wcsrtombs 
7 dalvik-main space (region space) (deleted) dalvik-main space @0x2772808e 
8 wcsrtombs 
9 js::Nursery::allocateObject js/src/gc/Nursery.cpp:277

Thank you, djc.

Nick, several of these stacks have ~LiveSavedFrameCache on them -- which is impossible, but could you take a look?
Flags: needinfo?(nfitzgerald)
Priority: -- → P1
Version: unspecified → Trunk
#5 top browser crash in FennecAndroid 58.0. Adding top crash keyword.
Snorp, is this something you can help out with?
Flags: needinfo?(snorp)
I think the JS team will need to handle it, but I think the general opinion is that JIT crashes are pretty unactionable unless we have specific STR. Maybe Jason will have more input now?
Flags: needinfo?(snorp) → needinfo?(jorendorff)
#8 top browser crash on Fennec 58.0.2.
Steven is this something you can help with?
Flags: needinfo?(sdetar)
This bug is part of the meta-bug Bug 858032. The enter functions got renamed from jit::EnterBaselineMethod into jit::MaybeEnterJit as part of Bug 1407607.

More precisely this bug might be related to Bug 1409978, which is specific to Android.

These bugs are usually non-actionable.

(In reply to Jason Orendorff [:jorendorff] from comment #1)
> Nick, several of these stacks have ~LiveSavedFrameCache on them -- which is
> impossible, but could you take a look?

These Android stacks are completely useless, there is no way these frame could happened to be ordered that way below MaybeEnterJit. These is more likely to be left-out garbage from the fact that our Interpreter frame is not well optimized by compilers and that the stack reconstruction fallback to just reading random pointers from what remains of the Interpreter frame in the stack.
Blocks: SadJit
Flags: needinfo?(sdetar)
Duplicate of this bug: 1447333
Lars, is this a dupe of MaybeEnterJit/LiveSavedFrameCache bug 1451720?

Flags: needinfo?(lhansen)
See Also: → 1451720
(In reply to Chris Peterson [:cpeterson] from comment #9)
> Lars, is this a dupe of MaybeEnterJit/LiveSavedFrameCache bug 1451720?

Oh, it might be.  It's certainly related, in that the traceback is useless junk...

As nbp says, all a crash in MaybeEnterJit means is that we're in jitted code.  If we can repro with a smallish test case (especially on something with devtools, like the simulator or an ARM dev board) it becomes more actionable.
Flags: needinfo?(lhansen)
The dom/base/crashtests/693212.xhtml testcase is pretty small. I don't have a device locally to test with, but here it is...
Attachment #8967186 - Attachment mime type: text/plain → text/xml
Let's call it a dup.
Closed: 5 years ago
Flags: needinfo?(nfitzgerald)
Flags: needinfo?(jorendorff)
Priority: P1 → P3
Resolution: --- → DUPLICATE
Duplicate of bug: 1451720
Duplicate of bug: SadJit
You need to log in before you can comment on or make changes to this bug.