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 =============================================================
Thank you, djc. Nick, several of these stacks have ~LiveSavedFrameCache on them -- which is impossible, but could you take a look?
Version: unspecified → Trunk
#5 top browser crash in FennecAndroid 58.0. Adding top crash keyword.
Snorp, is this something you can help out with?
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?
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.
Lars, is this a dupe of MaybeEnterJit/LiveSavedFrameCache bug 1451720? bp-1dc689bb-803a-48b4-89d0-070a90180411
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.
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.
Status: NEW → RESOLVED
Last Resolved: a year ago
Priority: P1 → P3
Resolution: --- → DUPLICATE
Duplicate of bug: 1451720
You need to log in before you can comment on or make changes to this bug.