Closed Bug 877377 Opened 12 years ago Closed 11 years ago

crash in JSAbstractFramePtr::getThisValue with Firebug

Categories

(Core :: JavaScript Engine, defect)

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

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox22 --- unaffected
firefox23 --- affected
firefox24 --- affected
firefox26 --- wontfix
firefox27 + wontfix
firefox28 - verified

People

(Reporter: scoobidiver, Unassigned)

References

Details

(4 keywords)

Crash Data

It first showed up in 23.0a1/20130403 but is discontinuous across builds. Signature JSAbstractFramePtr::getThisValue(JSContext*, JS::MutableHandle<JS::Value>) More Reports Search UUID cd0d3ca9-457b-4dd5-9800-e80642130529 Date Processed 2013-05-29 04:01:32 Uptime 92456 Last Crash 7.0 days before submission Install Age 1.1 days since version was first installed. Install Time 2013-05-28 02:20:22 Product Firefox Version 24.0a1 Build ID 20130527031027 Release Channel nightly OS Mac OS X OS Version 10.7.5 11G63 Build Architecture amd64 Build Architecture Info family 6 model 15 stepping 6 Crash Reason EXC_BAD_ACCESS / 0x0000000d Crash Address 0x0 App Notes AdapterVendorID: 0x1002, AdapterDeviceID: 0x68b8GL Layers? GL Context? GL Context+ GL Layers+ WebGL? WebGL+ Processor Notes sp-processor05_phx1_mozilla_com_20264:2012; exploitability tool: ERROR: unable to analyze dump EMCheckCompatibility True Adapter Vendor ID 0x1002 Adapter Device ID 0x68b8 Frame Module Signature Source 0 XUL JSAbstractFramePtr::getThisValue js/src/gc/Barrier.h:170 1 XUL jsd_NewThreadState js/jsd/jsd_stak.cpp:105 2 XUL XUL@0xebfaa0 3 XUL jsd_CallExecutionHook js/jsd/jsd_hook.cpp:134 4 XUL XUL@0xebfaa0 5 XUL jsd_DebugErrorHook js/jsd/jsd_high.cpp:391 6 XUL XUL@0x1d107c0 7 XUL ReportError js/src/jscntxt.cpp:443 8 XUL js_ReportErrorNumberVA js/src/jscntxt.cpp:894 9 XUL XUL@0x1d107c0 10 XUL JS_ReportErrorNumber js/src/jsapi.cpp:6596 11 libsystem_c.dylib libsystem_c.dylib@0xa03c8 12 XUL JS::LossyTwoByteCharsToNewLatin1CharsZ obj-firefox/x86_64/dist/include/js/Utility.h:152 13 XUL js_ValueToPrintable js/src/jsapi.h:4405 14 XUL bool js::FetchName<false> js/src/jsinterpinlines.h:389 15 XUL js::NameOperation js/src/jsinterpinlines.h:468 16 XUL js::Interpret js/src/jsinterp.cpp:2322 17 XUL XPCWrappedNative::GetNewOrUsed obj-firefox/x86_64/dist/include/nsAutoPtr.h:880 18 XUL SearchTable js/src/jsdhash.cpp:434 19 XUL XPCConvert::NativeInterface2JSObject obj-firefox/x86_64/dist/include/js/GCAPI.h:280 20 XUL nsWrapperCache::COMTypeInfo<int>::kIID 21 XUL js::RunScript js/src/jsinterp.cpp:353 22 XUL NS_IsMainThread obj-firefox/x86_64/xpcom/build/nsThreadUtils.cpp:137 ... More reports at: https://crash-stats.mozilla.com/report/list?signature=JSAbstractFramePtr%3A%3AgetThisValue%28JSContext*%2C+JS%3A%3AMutableHandle%3CJS%3A%3AValue%3E%29
There have been no crashes since 24.0a1/20130611.
status-firefox24: affected → unaffected
(In reply to Scoobidiver from comment #1) > There have been no crashes since 24.0a1/20130611. One crash in 24.0a2/20130720: bp-3108a3aa-0b1b-4ca1-b6fd-515862130726.
status-firefox24: unaffected → affected
…and again. Firebug 1.12.4, latest UX nightly.
This one crashes me on Firefox 26 on OSX at least once daily. Perhaps this has to do with multiple tabs/windows having firebug open at once? Is there a related Firebug bug I can look at? They must be sending defunct objects to the browser!
(In reply to David Woldrich from comment #7) I created a Firebug bug in case there wasn't one already: http://code.google.com/p/fbug/issues/detail?id=7103
This is the #1 Mac topcrasher on the 26 branch. It isn't even among the top 10 on the 25 branch. We must have done something to make it happen more often.
tracking-firefox26: --- → ?
Keywords: topcrash-mac
There are also crashes with a similar signature on Windows. Those tend to have better (more complete) stacks.
See Also: → 937631
This is also the #3 Mac topcrasher on the 27 branch.
tracking-firefox27: --- → ?
Interestingly, crashes with this (and similar) signatures are (basically) invisible on the 28 and 29 branches (on all platform). Conceivably we did something to "fix" them, or at least to avoid them.
STR would be extremely useful here. Shu, do you know if it's possible for Firebug/JSD to be enabled with Ion frames (from other compartments) on the stack? That could explain what's going on here, as we can't create an AbstractFramePtr for these frames. In a debug build this should assert but in an opt build it may not.
Flags: needinfo?(shu)
Keywords: steps-wanted
Also, if somebody can reproduce this, please download a debug build as well and see if you hit any asserts.
Keywords: qawanted
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101 Firefox/26.0 Reproduced this issue just once on Firefox 26 (build ID: 20131205075310) with Firebug 1.12.4 active while enabling desktop notifications for Gmail: https://crash-stats.mozilla.com/report/index/e1327559-9dd7-4b56-b62c-067812140109 Couldn't reproduce with other scenarios from crash stats comments nor with Firebug 1.12.5.
Keywords: qawanted
(In reply to Steven Michaud from comment #12) > Interestingly, crashes with this (and similar) signatures are (basically) > invisible on the 28 and 29 branches (on all platform). Conceivably we did > something to "fix" them, or at least to avoid them. That might also just be because of different audiences on the different channels.
(In reply to Jan de Mooij [:jandem] from comment #13) > STR would be extremely useful here. > > Shu, do you know if it's possible for Firebug/JSD to be enabled with Ion > frames (from other compartments) on the stack? That could explain what's > going on here, as we can't create an AbstractFramePtr for these frames. In a > debug build this should assert but in an opt build it may not. Since I haven't landed the on-stack Debugger patches yet, debug mode toggle still doesn't allow any scripts on stack. Last I checked, JSD is compartment-oblivious, so it should try to flip debug mode on for every single compartment. This should in theory ensure that no compartment has scripts on the stack, Ion or otherwise. As Jan said, STR would be great. Let me look at the stack trace a bit and see if I can make anything of it.
Flags: needinfo?(shu)
Bug 933882 landed in Nov, and this crash well predates Nov, so the crash is probably independent of that patch.
I agree with Jan that this is most likely because of an Ion frame on the stack. I don't see how this could be possible, however.
Is it possible that we are creating new compartments (globals) somehow while JSD is on, causing JIT code to be pushed onto the stack?
(In reply to Shu-yu Guo [:shu] from comment #20) > Is it possible that we are creating new compartments (globals) somehow while > JSD is on, causing JIT code to be pushed onto the stack? Jan found a debugMode on JSRuntime, which gets set by xpc when turning on/off JSD to make sure new compartments inherit debug mode from the runtime. So my theory is probably not correct.
The stack in comment 15 definitely looks like Ion is throwing an exception and JSD is trying to handle it. When JSD is turned on, it waits for all scripts to stop executing before doing anything. When it is turned off, it queues up a request for debugMode to be turned off when all currently executing scripts finish. But it also immediately clears almost all of its hook handlers (the one exception is not relevant here.) That means that even if debugMode hasn't been turned off yet, the JS engine still sees cx->runtime()->debugHooks.throwHook as set and invokes it, that goes to jsd_ThrowHandler, which looks at jsdc->throwHandler and *should* find it to be NULL and stop. In this case, jsdc->throwHandler is still set to jsd_CallExecutionHook which tries to look at the stack. <stream of consciousness continues> ...except that doesn't matter here. If there's a disable pending, then we started out with debugMode on, and ion wouldn't be running. So we know we're running ion code, from the above stack. That must have been compiled and started when debugMode was off for that compartment, and JSD itself must have been either off or paused. At some point, JSD was turned on. XPConnect waits until the ion script finishes running to do anything. So our script can't have been live. Argh. runtime->throwHook and jsdc->throwHandler both set to non-null means that JSD thinks it's totally up and running, with no debugMode=off pending. And it doesn't switch into that mode until the stack is empty, it's looped through all of the compartments discarding ion scripts, and sets their debugMode flags so no new ion code is generated. There's a known bug 957191 where XPConnect ignores an activation failure. But that would only result in XPConnect thinking JSD is on when it really isn't, and at worst the hooks wouldn't be set and you'd miss various events. That's the opposite of what's happening here. I'm kind of stumped.
(In reply to Alexandra Lucinet, QA Mentor [:adalucinet] from comment #15) > Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101 > Firefox/26.0 > > Reproduced this issue just once on Firefox 26 (build ID: 20131205075310) > with Firebug 1.12.4 active while enabling desktop notifications for Gmail: > https://crash-stats.mozilla.com/report/index/e1327559-9dd7-4b56-b62c- > 067812140109 > > Couldn't reproduce with other scenarios from crash stats comments nor with > Firebug 1.12.5. Ni to help understand if you are hitting this crash with the STR reliably ? That may help us a lot with the investigation the JS team is doing.
Flags: needinfo?(alexandra.lucinet)
(In reply to bhavana bajaj [:bajaj] from comment #23) > Ni to help understand if you are hitting this crash with the STR reliably ? > That may help us a lot with the investigation the JS team is doing. No, it was one time only crash when I enabled desktop notifications for Gmail. Couldn't reproduce with the same STR or other scenarios from users comments.
Flags: needinfo?(alexandra.lucinet)
Unfortunately this top-crasher would have to go unfixed this cycle due to lack of STR here. I am nominating this for Firefox 28 to see if this crash appears once we move onto beta cycle or confirm this is no longer an issue on Fx28.
tracking-firefox28: --- → ?
NI? on Kairo to check on this after 28.0b1 is out the door.
Flags: needinfo?(kairo)
Still need to know if this is a major issue for Firebug users on FF28 - it's been around a while, has it been worse lately than when it first appeared?
tracking-firefox28: + → ?
I see none of these (over the last 4 weeks) on the 28, 29 or 30 branches. I see 603 of these (over the last 4 weeks, Mac only) on the 27 branch. I think we can be pretty confident that this bug has somehow been "fixed".
> I see none of these (over the last 4 weeks) on the 28, 29 or 30 branches. Likewise with bug 937631.
OK. thanks for the feedback!
status-firefox28: --- → fixed
tracking-firefox28: ? → -
Steven, could you update bug 937631 with these information?
Flags: needinfo?(smichaud)
Done.
Flags: needinfo?(smichaud)
Flags: needinfo?(kairo)
Marking this verified fixed based on crash-stats. There are 0 reports of this crash against 28.0b in the last week. Steven, is there any reason to keep this bug report open?
status-firefox28: fixed → verified
> Steven, is there any reason to keep this bug report open? Not that I can think of. Since we don't know what "fixed" this bug and bug 937631, the fix might get undone, and these crashes might start happening again. But we don't need to worry about that until it happens ... if it ever does.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Resolution: FIXED → WORKSFORME
I am getting this bug with this test case: After I installed Firebug, and go to this URL: http://fc-solve.shlomifish.org/firefox-27.0.1-segfault-FOO/js-fc-solve/automated-tests/ (It's a more stable URL of the offending code) , quit firefox, start Firefox again, enable Firebug in a new window, enable the scripts' window, and reload that page a few time, then Firefox segfaults. I'm on Mageia Linux x86-64 5 / Cauldron and I've tried it in the linux-x86_64 distribution of Firefox from ftp.mozilla.org and it happens there too. I am using firefox-27.0.1 for linux-x86_64 from ftp.mozilla.org (official release). Here's a similar crash from clb on Mac OS X. It does not happen with nightly-30.0.0a1 as of today (also linux-x86_64): https://crash-stats.mozilla.com/report/index/7568e824-c104-4f06-a26f-a27702140314 I have logs for conversations about this bug on #firefox and on #emscripten (both on irc.mozilla.org ). It also happens with /usr/bin/firefox from firefox-27.0.1-1.mga5 (the Mageia rpm). Hope it helps. Regards, -- Shlomi Fish
This bug will be fixed in FF 28. Try a current FF 28 beta.
Hi Steven, (In reply to Steven Michaud from comment #36) > This bug will be fixed in FF 28. Try a current FF 28 beta. Are you addressing me? The reason I posted my comment was because people wanted steps to reproduce (STR) and it affected the 27.x Firefoxes I was using. I will try it again with a Firefox 28 beta. Regards, -- Shlomi Fish
(In reply to Shlomi Fish from comment #37) > Hi Steven, > > (In reply to Steven Michaud from comment #36) > > This bug will be fixed in FF 28. Try a current FF 28 beta. > > Are you addressing me? The reason I posted my comment was because people > wanted steps to reproduce (STR) and it affected the 27.x Firefoxes I was > using. I will try it again with a Firefox 28 beta. > It works fine with firefox-28.0b9 beta from ftp.mozilla.org. Regards, -- Shlomi Fish
Looking at the crash stats (over the last 4 weeks) for the 28 branch and up, this crash *doesn't* seem to have disappeared completely. But it's happening much less often than previously: It's the #90 Mac crasher on the 29 branch, and #60 on the 30 branch. (For the moment at least, there aren't any on the 31 and 32 branches.) So, very reluctantly, I'll reopen this bug. But it's unlikely we'll be able to do anything about it until/unless we find out how to reproduce it.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I would actually prefer we opened a new bug for follow-up, unless of course we plan to back out the changes landed previously.
status-firefox27: affected → wontfix
Also, removing the topcrash keyword makes it really difficult to query on which topcrashes we've fixed.
Keywords: topcrash-mac
> I would actually prefer we opened a new bug for follow-up OK, makes sense. Will do.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.