This bug was filed from the Socorro interface and is
report bp-8cc9c0b1-c94c-4c7a-aa06-170fa2120910 .
0 libSystem.B.dylib libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_x86_6
1 libobjc.A.dylib objc_addExceptionHandler
2 CoreFoundation _CFDoExceptionOperation
3 AppKit _NSAppKitLock
4 AppKit -[NSCGSContext _invalidate]
5 AppKit -[NSCGSContext dealloc]
6 AppKit -[NSWindowGraphicsContext dealloc]
7 AppKit -[NSBitmapGraphicsContext dealloc]
8 AppKit -[NSSnapshotBitmapGraphicsContext dealloc]
9 AppKit +[NSCGImageSnapshotRep _unlockFocusAndPerformBlockUsingCGImageAndCapturingContex
10 AppKit +[NSCGImageSnapshotRep unlockFocusCreatingCGImageSnapshotRep]
11 AppKit -[NSImage unlockFocus]
12 AppKit -[NSDockTile _drawBadgeLabel]
13 AppKit -[NSDockTile display]
14 XUL nsMessengerOSXIntegration::BadgeDockIcon mailnews/base/src/nsMessengerOSXIntegration.mm:645
15 XUL nsMessengerOSXIntegration::OnItemIntPropertyChanged mailnews/base/src/nsMessengerOSXIntegration.mm:537
16 XUL nsMsgMailSession::OnItemIntPropertyChanged mailnews/base/src/nsMsgMailSession.cpp:132
17 XUL nsMsgDBFolder::NotifyIntPropertyChanged mailnews/base/util/nsMsgDBFolder.cpp:4916
18 XUL nsMsgDBFolder::UpdateSummaryTotals mailnews/base/util/nsMsgDBFolder.cpp:4090
19 XUL nsMsgDBFolder::OnHdrFlagsChanged mailnews/base/util/nsMsgDBFolder.cpp:1005
20 XUL nsMsgDatabase::NotifyHdrChangeAll mailnews/db/msgdb/src/nsMsgDatabase.cpp:836
21 XUL nsMsgDatabase::MarkHdrReadInDB mailnews/db/msgdb/src/nsMsgDatabase.cpp:2134
22 XUL nsMsgDatabase::MarkHdrRead mailnews/db/msgdb/src/nsMsgDatabase.cpp:2574
23 XUL nsMsgDatabase::MarkRead mailnews/db/msgdb/src/nsMsgDatabase.cpp:2147
24 XUL nsMsgHdr::MarkRead mailnews/db/msgdb/src/nsMsgHdr.cpp:228
25 XUL nsMsgDBFolder::MarkMessagesRead mailnews/base/util/nsMsgDBFolder.cpp:4680
26 XUL nsImapMailFolder::MarkMessagesRead mailnews/imap/src/nsImapMailFolder.cpp:1886
27 XUL NS_InvokeByIndex_P xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_unix.cpp:163
28 XUL XPCWrappedNative::CallMethod js/xpconnect/src/XPCWrappedNative.cpp:3151
29 XUL XPC_WN_CallMethod js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1500
30 XUL js::InvokeKernel js/src/jscntxtinlines.h:395
31 XUL js::Interpret js/src/jsinterp.cpp:2515
need try-catch block for Objective-C.
Created attachment 662053 [details] [diff] [review]
I'm not convinced this is the only case, I've had crashes when opening the troubleshooting information tab today, and this is with a different stack:
I see the value of adding missing Obj-C try/catch blocks, and I'm sure there are plenty of places we need them, but we also need to figure out why our Obj-C code is throwing exceptions in the first place.
Mark, your three crashes are mozilla::gl::CreateOffscreenFBOContext at gfx/gl/GLContextProviderCGL.mm:69. That file has lots of Obj-C method calls without try/catch; not sure if we care (or can find out) which of them can potentially throw.
Based on a scattered sample, the 10.7 crashes appear to be in nsLookAndFeel::NativeGetColor widget/cocoa/nsLookAndFeel.mm:208
Most of the 10.8 stacks don't make a lot of sense but I saw one that traces back to nsLookAndFeel::NativeGetColor widget/cocoa/nsLookAndFeel.mm:126
I haven't been able to reproduce with the release TB 15.0.1 yet.
I did an almost straight rebuild of 15.0.1 today on try server:
Nothing obvious showed up in the unit tests, but the build still crashes when I try and access the troubleshooting information.
I'm going to set off two more try builds in a bit: one without the gecko changes in 15.0.1, one without the Thunderbird specific changes in 15.0.1.
This one is based on gecko 15.0, but with the Thunderbird specific 15.0.1 changes. I've not made it crash yet, but I do need to do some more testing on it:
I'm not having any luck reproducing this, though Ehsan (in our office) has seen it.
One thing I noticed looking back through the stacks on both 10.6 and 10.7 is that they are under nsThread::Shutdown(), stopping a load from nsJarChannel, which is triggering CSS processing. I don't know what conditions would cause us to shut down the main thread in the middle of loading content - could it be seeing a partially applied update and trying to restart into it or something like that?
Comment on attachment 662053 [details] [diff] [review]
I just spoke to Irving, and we decided to take this. Although we haven't found the root cause of the exception, we're interested to see if this changes anything should the crashes continue past 16.0.
Hence r=me, and we'll take this onto the branches as well.
Calling this "fixed" for tracking purposes, but we may need to open another bug/extend an existing one if this continues past the 16 release.
(In reply to Mark Banner (:standard8) from comment #10)
> Checked in:
> Calling this "fixed" for tracking purposes, but we may need to open another
> bug/extend an existing one if this continues past the 16 release.
just to be clear, there are currently zero crashes for all branches except 15.
but I have someone who might be able to test
(In reply to Irving Reid (:irving) from comment #8)
> I'm not having any luck reproducing this, though Ehsan (in our office) has
> seen it.
did this stop Ehsan's crashes? Or was he not able to reproduce enough?
> One thing I noticed looking back through the stacks on both 10.6 and 10.7 is
> that they are under nsThread::Shutdown(), stopping a load from nsJarChannel,
> which is triggering CSS processing. I don't know what conditions would cause
> us to shut down the main thread in the middle of loading content - could it
> be seeing a partially applied update and trying to restart into it or
> something like that?
I'll point out that Mac users often report that reinstalling TB is needed after an update to fix startup problems. much moreso than windows. So perhaps you are on to something. Does that theory still hold water for you?
(In reply to comment #11)
> (In reply to Irving Reid (:irving) from comment #8)
> > I'm not having any luck reproducing this, though Ehsan (in our office) has
> > seen it.
> did this stop Ehsan's crashes? Or was he not able to reproduce enough?
I only ever saw that crash once.
reports so far where crash is gone:
- crash-stats https://crash-stats.mozilla.com/query/query?product=Thunderbird&version=Thunderbird%3A16.0.1&version=Thunderbird%3A19.0a1&version=Thunderbird%3A18.0a2&version=Thunderbird%3A18.0a1&version=Thunderbird%3A17.0b1&version=Thunderbird%3A17.0a2&version=Thunderbird%3A16.0b4&version=Thunderbird%3A16.0b3&range_value=2&range_unit=weeks&date=10%2F20%2F2012+16%3A26%3A59&query_search=signature&query_type=contains&query=libunwind%3A%3AUnwindCursor&reason=&build_id=&process_type=any&hang_type=any&do_query=1