1425132 - Crash in js::jit::MaybeEnterJit

Status: RESOLVED DUPLICATE of bug 858032

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

Description

[Dirkjan Ochtman (:djc)]

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

=============================================================

Comment 1

[Jason Orendorff [:jorendorff]]

Thank you, djc.

Nick, several of these stacks have ~LiveSavedFrameCache on them -- which is impossible, but could you take a look?

Comment 2

[Marcia Knous [:marcia]]

#5 top browser crash in FennecAndroid 58.0. Adding top crash keyword.

Comment 3

[Nicole Yee (:nicoleyee)]

Snorp, is this something you can help out with?

Comment 4

[James Willcox (:snorp) ([e-mail]) (he/him)]

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?

Comment 5

[Marcia Knous [:marcia]]

#8 top browser crash on Fennec 58.0.2.

Comment 6

[Marcia Knous [:marcia]]

Steven is this something you can help with?

Comment 7

[Nicolas B. Pierron [:nbp]]

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.

Comment 9

[Chris Peterson [:cpeterson]]

Lars, is this a dupe of MaybeEnterJit/LiveSavedFrameCache bug 1451720?

bp-1dc689bb-803a-48b4-89d0-070a90180411

Comment 10

[Lars T Hansen [:lth]]

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

Comment 11

[Bob Clary [:bc] (inactive)]

Attachment: dom/base/crashtests/693212.xhtml

The dom/base/crashtests/693212.xhtml testcase is pretty small. I don't have a device locally to test with, but here it is...

Comment 12

[Jason Orendorff [:jorendorff]]

Let's call it a dup.