Closed Bug 670603 Opened 13 years ago Closed 12 years ago

Crash at js::mjit::JaegerShot

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Version:
6 Branch
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla23
Tracking Flags:
Tracking Status
firefox23 --- disabled

People

(Reporter: scoobidiver, Assigned: dvander)

References

Details

(Keywords: crash, meta, topcrash, Whiteboard: [native-crash])

Crash Data

It is #8 top crasher in 6.0. Many comments talk about writing, checking or deleting e-mails in the new Yahoo mail interface. Frame Module Signature [Expand] Source 0 @0x6779e7e4 1 mozjs.dll js::mjit::JaegerShot js/src/methodjit/MethodJIT.cpp:732 2 mozjs.dll js::Invoke js/src/jsinterp.cpp:694 3 mozjs.dll JS_CallFunctionValue js/src/jsapi.cpp:5080 4 xul.dll nsXPCWrappedJSClass::CallMethod js/src/xpconnect/src/xpcwrappedjsclass.cpp:1662 5 xul.dll nsXPCWrappedJS::CallMethod js/src/xpconnect/src/xpcwrappedjs.cpp:586 6 xul.dll PrepareAndDispatch xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114 7 xul.dll SharedStub xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141 8 xul.dll nsDOMEventListenerWrapper::HandleEvent content/events/src/nsDOMEventTargetHelper.cpp:65 9 xul.dll nsEventListenerManager::HandleEventSubType content/events/src/nsEventListenerManager.cpp:1142 Frame Module Signature [Expand] Source 0 @0x1dd06680 1 mozjs.dll js::mjit::JaegerShot js/src/methodjit/MethodJIT.cpp:732 2 mozjs.dll js::Invoke js/src/jsinterp.cpp:694 3 mozjs.dll JS_CallFunctionValue js/src/jsapi.cpp:5080 4 xul.dll nsJSContext::CallEventHandler dom/base/nsJSEnvironment.cpp:1906 5 xul.dll nsGlobalWindow::RunTimeout dom/base/nsGlobalWindow.cpp:9209 6 xul.dll nsGlobalWindow::TimerCallback dom/base/nsGlobalWindow.cpp:9554 7 xul.dll nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp:424 8 xul.dll nsTimerEvent::Run xpcom/threads/nsTimerImpl.cpp:520 9 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:618 10 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:134 ... More reports at: https://crash-stats.mozilla.com/report/list?signature=js%3A%3Amjit%3A%3AJaegerShot%28JSContext*%29 https://crash-stats.mozilla.com/report/list?signature=js%3A%3Amjit%3A%3AJaegerShot
We are going to track this so we can verify the fix works. We missed b1 so we will need to verify in b2.
tracking-firefox6: ? → +
Do we have enough data for 6b2 to verify this fix and set the status-firefox6 to fixed?
(In reply to comment #4) > Do we have enough data for 6b2 to verify this fix and set the > status-firefox6 to fixed? It still crashes: bp-d1bbb9af-59e9-4555-b12d-1320b2110717 on Windows bp-8e15446e-e15d-4b7d-a722-ba4a92110717 on Mac OS X bp-ad77b244-8879-4aee-8f9a-0d56b2110717 on Linux But it seems to be below #300 top crasher and maybe unrelated to Yahoo mail. Tracking for Firefox 6 is no longer required.
Untracking for 6.0.
tracking-firefox6: + → ---
Depends on: CVE-2011-2991
There have been only 7 crashes over the last four weeks in 7.0a2 and 74 crashes in 6.0 since 6.0b2. I removed the reference to Yahoo mail in the bug summary as it is no longer correlated to it.
Summary: Crash at js::mjit::JaegerShot in Yahoo mail → Crash at js::mjit::JaegerShot
Hardware: x86 → All
This is really low volume and I only see 2 on FennecAndroid in 3 weeks.
There's a spike in crashes starting from 16.0a1/20120606 (#7 in this build). The regression range for the spike is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a7a905fd70d5&tochange=6338a8988917 Comments say: "Clicked Reply All button in gmail." "Opened a new tab from netflix.com"
tracking-firefox16: --- → ?
Keywords: topcrash
Whiteboard: [mobile-crash]
Hopefully we have a fix to this in bug 761863.
(In reply to Luke Wagner [:luke] from comment #12) > Hopefully we have a fix to this in bug 761863. It's no longer a top crasher in 16.0a1.
Keywords: topcrash
Given that, untracking.
tracking-firefox16: ? → -
There's a spike in crashes starting from 18.0a1/20120909. The regression range for the spike might be: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1d4fc0c60063&tochange=f31d1aa89848
Crash Signature: [@ js::mjit::JaegerShot(JSContext*) ] [@ js::mjit::JaegerShot ] → [@ js::mjit::JaegerShot(JSContext*, bool) ] [@ js::mjit::JaegerShot(JSContext*) ] [@ js::mjit::JaegerShot ]
Whiteboard: [native-crash]
It's #6 top browser crasher in desktop Firefox 18.0b1. See comment 15 for the regression range.
tracking-firefox18: --- → ?
Keywords: topcrash
David - sounds like this has gotten significantly worse in desktop w/ the change to IonMonkey. Can somebody take a look?
Assignee: general → dvander
Still #8 in 18.0b2 - dvander, anything we can do to get some insight there?
Flags: needinfo?(dvander)
This is really a meta bug, unactionable like GC marking crash signatures, since any sort of memory corruption or random bug has a pretty high chance of crashing in the execution engine. If we get specific STR we can roll with that as its own bug, otherwise fuzzing and fixing known reproducible crashes generally help a lot more toward improving general stability.
Flags: needinfo?(dvander)
(In reply to David Anderson [:dvander] from comment #20) > This is really a meta bug, unactionable like GC marking crash signatures, > since any sort of memory corruption or random bug has a pretty high chance > of crashing in the execution engine. If we get specific STR we can roll with > that as its own bug, otherwise fuzzing and fixing known reproducible crashes > generally help a lot more toward improving general stability. Can any in-product changes be made to make the root causes of these crashes more evident? For instance, the mobile team has recently started including logcat info when crashing (bug 815684). I know these are very different worlds, but I'm hoping it inspires you nonetheless :)
Depends on: 822438
Untracking it for FF18 at this time.If David, can't think of anything we can do in the Beta 19 timeframe, we'll untrack for all upcoming releases.Please let us know if we can help with anything here to make it actionable.
status-firefox17: --- → wontfix
status-firefox18: --- → wontfix
tracking-firefox19: --- → ?
(In reply to bhavana bajaj [:bajaj] from comment #22) > Untracking it for FF18 at this time.If David, can't think of anything we can > do in the Beta 19 timeframe, we'll untrack for all upcoming releases.Please > let us know if we can help with anything here to make it actionable. (In reply to Alex Keybl [:akeybl] from comment #21) > Can any in-product changes be made to make the root causes of these crashes > more evident? Probably the most helpful thing would be if breakpad could somehow give us a JavaScript callstack in addition to the C++ callstack. I don't know much about breakpad but it could be possible if breakpad could jam the text of the callstack into an extra section of the minidump. Definitely privacy issues there, though. With that, it might be possible to find patterns of where things are crashing. For example, the PGO bug which manifested in JITs, happened around calls to Math.pow(). Or in the TraceMonkey days, just knowing which loop something crashed in was often enough to derive a working test case.
Ted, see comment #23, I know we have some parts of memory in the minidump, do those help here? Can we get the info dvander wants into reports in some way?
We can add arbitrary memory to the minidump, as well as arbitrary annotations to the crash report. The only difficulty is that you either have to provide this info ahead-of-time, or be able to gather it in a memory-safe manner in the exception handler (no heap allocations, no calls to external shared libraries, etc). We have some existing JS crash diagnostics which save the (native) stack whenever we GC, so that we can determine what was happening during the last GC: http://mxr.mozilla.org/mozilla-central/ident?i=JS_CRASH_DIAGNOSTICS billm added those, he can tell you more about them. Privacy-wise, we already send the URL of the page you were visiting and the native stack, so I don't think sending the JS stack is really any worse.
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #25) > We can add arbitrary memory to the minidump, as well as arbitrary > annotations to the crash report. The only difficulty is that you either have > to provide this info ahead-of-time, or be able to gather it in a memory-safe > manner in the exception handler (no heap allocations, no calls to external > shared libraries, etc). I've forgotten what little I knew about breakpad, but I thought that annotation code had to access memory through ptrace-style calls. Is that not true?
On Linux the minidump writer clone()s the current process and uses ptrace for all its memory access, yes. You added an API to breakpad to register additional memory regions to be included in the dump, and the JS_CRASH_DIAGNOSTICS code simply registers its buffer and stuffs data in there at runtime.
This is now a longstanding issue that we'll no longer track for a specific version of Firefox. We should continue to pursue a change to breakpad to be able to split this bug into actionable issues.
tracking-firefox19: + → -
I heard that there's a new baseline compiler in 22 that is replacing jaegermonkey? Is that correct? Is there any use of trying to figure out before the baseline compiler? Or should we just wait it out? Trying to understand how much time we should spend in finding STRs esp if it's hard to find.
We're not sure what release it will ship in yet, but it looks on schedule for <= 24. If STR is found for any crash inside JIT code, that is extremely helpful, but by this point it seems unlikely we'll find any outside fuzzing. Given that, I'd say yeah, let's see what happens to overall JIT crashes once the baseline compiler lands.
All the crashes are old. I think they morphed to ionmonkey. Removing topcrash.
Keywords: topcrash
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #33) > All the crashes are old. I think they morphed to ionmonkey. Removing > topcrash. It's #6 top browser crasher on desktop Firefox 20.0.1, #5 on desktop Firefox 21.0b3, #12 on desktop Firefox 22.0a2 and fixed in 23.0a1 so don't remove the topcrash keyword. See https://wiki.mozilla.org/CrashKill/Topcrash.
Keywords: topcrash
Jaegermonkey is disabled in 23, which is why they won't show up there. JM has been replaced by the BaselineCompiler, not IonMonkey per se. Though I guess BC crashes may show up with IM in the stacks.
status-firefox17: wontfix → ---
status-firefox18: wontfix → ---
status-firefox19: affected → ---
status-firefox23: --- → disabled
tracking-firefox16: - → ---
tracking-firefox18: + → ---
tracking-firefox19: - → ---
(In reply to Andrew McCreight [:mccr8] from comment #35) > Jaegermonkey is disabled in 23, which is why they won't show up there. Let's close this meta tracker as fixed because disabled doesn't exist.
Status: NEW → RESOLVED
Closed: 12 years ago
Keywords: meta
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
You need to log in before you can comment on or make changes to this bug.