Closed Bug 422823 Opened 18 years ago Closed 18 years ago

topcrash [@ nsObjCExceptionLogAbort(NSException*)]

Categories

(Core :: Widget: Cocoa, defect)

Product:
Core
Component:
Widget: Cocoa
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: samuel.sidler+old, Assigned: jaas)

References

(
URL
)

Details

(Keywords: crash, topcrash)

Crash Data

Our #1 Firefox 3 beta 4 topcrash on Mac is happening in nsObjCExceptionLogAbort(NSException*). Sample stack from bp-cd44daf8-f082-11dc-bec0-001a4bd43ef6: 0 nsObjCExceptionLogAbort(NSException*) mozilla/widget/src/cocoa/nsCocoaWindow.mm:63 1 -[NSWindow(MethodSwizzling) nsCocoaWindow_NSWindow_sendEvent:] mozilla/widget/src/cocoa/nsCocoaWindow.mm:2035 2 AppKit@0xdb713 3 nsAppShell::ProcessNextNativeEvent(int) mozilla/widget/src/cocoa/nsAppShell.mm:507 4 nsBaseAppShell::DoProcessNextNativeEvent(int) mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:133 5 nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, int, unsigned int) mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:234 6 nsAppShell::OnProcessNextEvent(nsIThreadInternal*, int, unsigned int) mozilla/widget/src/cocoa/nsAppShell.mm:655 7 nsThread::ProcessNextEvent(int, int*) mozilla/xpcom/threads/nsThread.cpp:497 8 NS_ProcessPendingEvents_P(nsIThread*, unsigned int) nsThreadUtils.cpp:180 9 nsBaseAppShell::NativeEventCallback() mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:107 10 nsAppShell::ProcessGeckoEvents(void*) mozilla/widget/src/cocoa/nsAppShell.mm:305 11 CoreFoundation@0x7262d 12 CoreFoundation@0x72d17 13 HIToolbox@0x3069f 14 HIToolbox@0x304b8 15 HIToolbox@0x3032c 16 AppKit@0x407d8 17 AppKit@0x4008d 18 AppKit@0x1117fe 19 AppKit@0x693450 20 AppKit@0x69019f 21 AppKit@0x6963d8 22 AppKit@0x10eac2 23 -[NSWindow(MethodSwizzling) nsCocoaWindow_NSWindow_sendEvent:] mozilla/widget/src/cocoa/nsCocoaWindow.mm:2011 24 AppKit@0xdb713 25 AppKit@0x27cf42 26 AppKit@0x277656 27 AppKit@0x268750 28 nsFilePicker::GetLocalFiles(nsString const&, int, nsCOMArray<nsILocalFile>&) mozilla/widget/src/cocoa/nsFilePicker.mm:263 29 nsFilePicker::Show(short*) mozilla/widget/src/cocoa/nsFilePicker.mm:204 30 nsFileControlFrame::MouseClick(nsIDOMEvent*) mozilla/layout/forms/nsFileControlFrame.cpp:345 31 nsEventListenerManager::HandleEvent(nsPresContext*, nsEvent*, nsIDOMEvent**, nsISupports*, unsigned int, nsEventStatus*) mozilla/content/events/src/nsEventListenerManager.cpp:184 32 nsEventTargetChainItem::HandleEvent(nsEventChainPostVisitor&, unsigned int) mozilla/content/events/src/nsEventDispatcher.cpp:206 33 nsEventTargetChainItem::HandleEventTargetChain(nsEventChainPostVisitor&, unsigned int, nsDispatchingCallback*) mozilla/content/events/src/nsEventDispatcher.cpp:264 34 nsEventTargetChainItem::HandleEventTargetChain(nsEventChainPostVisitor&, unsigned int, nsDispatchingCallback*) mozilla/content/events/src/nsEventDispatcher.cpp:316 35 nsEventDispatcher::Dispatch(nsISupports*, nsPresContext*, nsEvent*, nsIDOMEvent*, nsEventStatus*, nsDispatchingCallback*) mozilla/content/events/src/nsEventDispatcher.cpp:479 36 PresShell::HandleEventInternal(nsEvent*, nsIView*, nsEventStatus*) mozilla/layout/base/nsPresShell.cpp:5895 37 PresShell::HandleEventWithTarget(nsEvent*, nsIFrame*, nsIContent*, nsEventStatus*) mozilla/layout/base/nsPresShell.cpp:5800 38 nsEventStateManager::CheckForAndDispatchClick(nsPresContext*, nsMouseEvent*, nsEventStatus*) mozilla/content/events/src/nsEventStateManager.cpp:3356 39 nsEventStateManager::PostHandleEvent(nsPresContext*, nsEvent*, nsIFrame*, nsEventStatus*, nsIView*) mozilla/content/events/src/nsEventStateManager.cpp:2420 40 PresShell::HandleEventInternal(nsEvent*, nsIView*, nsEventStatus*) mozilla/layout/base/nsPresShell.cpp:5916 41 PresShell::HandlePositionedEvent(nsIView*, nsIFrame*, nsGUIEvent*, nsEventStatus*) mozilla/layout/base/nsPresShell.cpp:5783 42 PresShell::HandleEvent(nsIView*, nsGUIEvent*, nsEventStatus*) mozilla/layout/base/nsPresShell.cpp:5636 43 nsViewManager::HandleEvent(nsView*, nsPoint, nsGUIEvent*, int) mozilla/view/src/nsViewManager.cpp:1396 44 nsViewManager::DispatchEvent(nsGUIEvent*, nsEventStatus*) mozilla/view/src/nsViewManager.cpp:1351 45 HandleEvent(nsGUIEvent*) mozilla/view/src/nsView.cpp:168 46 nsChildView::DispatchEvent(nsGUIEvent*, nsEventStatus&) mozilla/widget/src/cocoa/nsChildView.mm:1544 47 nsChildView::DispatchWindowEvent(nsGUIEvent&) mozilla/widget/src/cocoa/nsChildView.mm:1557 48 nsChildView::DispatchMouseEvent(nsMouseEvent&) mozilla/widget/src/cocoa/nsChildView.mm:1569 49 -[ChildView mouseUp:] mozilla/widget/src/cocoa/nsChildView.mm:2867 50 AppKit@0x10eb60 51 -[NSWindow(MethodSwizzling) nsCocoaWindow_NSWindow_sendEvent:] mozilla/widget/src/cocoa/nsCocoaWindow.mm:2011 52 AppKit@0xdb713 53 AppKit@0x390f8 54 nsAppShell::Run() mozilla/widget/src/cocoa/nsAppShell.mm:587 55 nsAppStartup::Run() mozilla/toolkit/components/startup/src/nsAppStartup.cpp:181 56 XRE_main mozilla/toolkit/xre/nsAppRunner.cpp:3149 57 main mozilla/browser/app/nsBrowserApp.cpp:158 58 start crt.c:272 59 start 60 @0x1 Some sample comments: Was trying to attach a file to a gmail, with the standard "attach file" / "open file" diaglog. Was idling at Craigslist when it crashed. Was attaching two PDF files to an e-mail using hotmail.com when Firefox 3 beta 4 crashed. Using Places on flickr.com. Using Command-Option-Z as a shortcut key for Zoom action in Firefox. trying to select a file for upload to twitter icon man this release is buggy Trying to open preferences for Scrapbook extension from tools menu trying to 'save as' an image from internet. some conflict with the dialog choosing destination of the jpg on mac os x 10.4.11 tried to save a picture to my harddrive tried to save a jpeg. created a new folder for it. Tried to make a PDF file using the "Save as PDF" option in the Print menu. save animated gif as ... could not write the name, wanted to save it in dialog, crash after save Browsing for a file to upload on youtube... Crashed while trying to download six files from www. audible.com Firefox crashes every time I try and upload a file. Firefox got stuck in a dialog box, when I was "Choosing the application" to open a certain file. This latest beta seems to get stuck once in a while when there's a dialog box for a "Save/Open file" or "Choosing an application" to open a file hi I was trying to send a file through Earthlink and Firefox crashed. I was attempting to save an embedded photo to the desktop from AOL's Webmail i was browsing for pics on my mac to post on my space Most of the above seem to be related to the use of the native "open" and "save" dialogs and working with them. However, there are comments that seem to imply working with menus and/or key commands can also cause this crash.
Flags: blocking1.9?
Also note that I looked at 20 or so reports and all had swizzling near the top of the crashing thread.
It's possible that the patch for bug 419668 may fix these. There's a tryserver build at bug 419668 comment #26 (not final).
> -[NSWindow(MethodSwizzling) nsCocoaWindow_NSWindow_sendEvent:] All this means is that the crashes are triggered by the OS sending a Cocoa event to an NSWindow object. > nsObjCExceptionLogAbort(NSException*) > mozilla/widget/src/cocoa/nsCocoaWindow.mm:63 This means that the new handlers for Objective-C exceptions caught an Objective-C exception and forced a crash. Information on which exception was caught will usually be in the console log. So you guys need to remember to ask people who see these crashes to look in their console log. (For more information on the new handlers see bug 163260.)
> nsObjCExceptionLogAbort(NSException*) > mozilla/widget/src/cocoa/nsCocoaWindow.mm:63 As Josh keeps saying, this will now _always_ be in the topcrash list -- because this will be at the top of _every_ crash triggered by the new handlers for Objective-C exceptions (regardless of where the exception took place and which exception it was).
> nsObjCExceptionLogAbort(NSException*) Actually it's only this much that will be at the top of every stack.
Should we try to get breakpad to collect more useful information for these crashes, such as the text of the exception that was caught? And maybe even group them by Cocoa exception rather than grouping them all as one topcrash called "nsObjCExceptionLogAbort"?
we should be able to ask the user for permission to upload /Library/Logs/Console/$user/console.log is this bug about breakpad or about some specific crash? (because this isn't a specific crash, but if it's about breakpad it's in the wrong component.)
> we should be able to ask the user for permission to upload > /Library/Logs/Console/$user/console.log This file can be enormous, and contain lots of extraneous information. It's also only available on OS X 10.4.X. (I haven't yet found out where the console log is stored on Leopard, and (as far as I know) Apple hasn't documented its location.) > Should we try to get breakpad to collect more useful information for > these crashes, such as the text of the exception that was caught? > And maybe even group them by Cocoa exception rather than grouping > them all as one topcrash called "nsObjCExceptionLogAbort"? Yes, that would be wonderful. But I suspect this would only be possible if the code that handles Objective-C exceptions can talk directly to Breakpad (or to some kind of Breakpad proxy). > is this bug about breakpad or about some specific crash? At this point it's about both :-)
> (or to some kind of Breakpad proxy) Which could be as simple as writing the info to a file with a predefined name in a predefined location (where Breakpad can look for it once it's running).
Here's a tryserver build made with the latest patches for bug 419668 and bug 409615. It's possible that these patches will fix many (most?) of these crashes. https://build.mozilla.org/tryserver-builds/2008-03-14_10:55-smichaud@mozilla.com-bugzilla419668-409615/smichaud@mozilla.com-bugzilla419668-409615-firefox-try-mac.dmg
Until we have more info about what exactly this bug is about blocking1.9-. A topcrash with nsObjCExceptionLogAbort on the stack isn't enough. There's a good chance Steven's patch will get this anyway.
Flags: blocking1.9? → blocking1.9-
(In reply to comment #8) > > we should be able to ask the user for permission to upload > > /Library/Logs/Console/$user/console.log > > This file can be enormous, and contain lots of extraneous information. > It's also only available on OS X 10.4.X. (I haven't yet found out > where the console log is stored on Leopard, and (as far as I know) > Apple hasn't documented its location.) It should be trivial to filter the console log by the product name (e.g., "firefox" to catch messages from "org.mozilla.firefox" and "firefox-bin") and append only those relevant entries of recent vintage to some sort of record that mozCrashreporter can pick up; Camino Diagnostics currently does that as part of its diagnostic output. (man syslog for more info, generally speaking) Getting mozCrashreporter to do it and then getting it into the Socorro database is another thing entirely, and certainly not this bug.
Another (related? same?) crash that seems to happen a lot for users uploading to flickr, wordpress etc: bug 427167
looks like nsObjCExceptionLogAbort(NSException*) might still be around the #7 top crash in beta 5, but the stacksignatures now look more like 0 XUL nsObjCExceptionLogAbort mozilla/toolkit/xre/MacApplicationDelegate.mm:63 1 AppKit AppKit@0x252bd0 2 AppKit AppKit@0x3e454 3 HIServices HIServices@0x1e454 4 HIServices HIServices@0x1e38c 5 HIServices HIServices@0x4624 6 HIServices HIServices@0x4514 7 CoreFoundation CoreFoundation@0x3163c 8 CoreFoundation CoreFoundation@0x31550 9 CoreFoundation CoreFoundation@0x23c68 10 CoreFoundation CoreFoundation@0x23298 where users are trying to shutdown. Then there are other actions with other stack traces. might be time to go deeper on the analysis and get more bugs filed for those differing stacktraces. still not much to go on in commments but this is the place to watch http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&range_unit=weeks&version=Firefox%3A3.0b5&signature=nsObjCExceptionLogAbort(NSException*)&range_value=1
So as already have been mentioned, *any* crash that is due to us making a bad OS call will end with this signature, so what's interesting is the first non-nsObjCExceptionLogAbort-frame in the stack that comes from us. I had a look in the list, and saw a bunch of MacApplicationDelegate crashes, like chofmann's above. If they're shutdown crashes, I'll bet that it is because the OS is calling our delegate to do things when we're partly torn down. One example is b429408a-05aa-11dd-a18b-001b78bc73ea which could be us doing calls to a partly torn down NSWindow when the app is shutting down. Looking at the code, I notice that MacApplicationDelegate is indeed around for the lifetime of the app. I think we should clear it out when we're beginning our shutdown path, to make sure we're not starting to build dock menus (with bad NSWindow*s) or any stuff like that.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
Crash Signature: [@ nsObjCExceptionLogAbort(NSException*)]
You need to log in before you can comment on or make changes to this bug.