Closed Bug 790234 Opened 12 years ago Closed 12 years ago

[10.6] crash in libunwind::UnwindCursor

Categories

(Thunderbird :: OS Integration, defect)

15 Branch
x86_64
macOS
defect
Not set
critical

Tracking

(thunderbird16 fixed, thunderbird17 fixed)

VERIFIED FIXED
Thunderbird 18.0
Tracking Status
thunderbird16 --- fixed
thunderbird17 --- fixed

People

(Reporter: Usul, Assigned: m_kato)

References

()

Details

(Keywords: crash, regression, Whiteboard: [gs])

Crash Data

Attachments

(1 file)

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
Keywords: regression
Hardware: All → x86_64
Summary: crash in libunwind::UnwindCursor → [10.6] crash in libunwind::UnwindCursor
need try-catch block for Objective-C.
Attached patch possible fix (deleted) — Splinter Review
Attachment #662053 - Flags: review?(mbanner)
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: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/try-builds/bugzilla@standard8.plus.com-84229c5cb54d/try-comm-central-macosx64/ 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: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/try-builds/bugzilla@standard8.plus.com-e5945169b9f9/try-comm-central-macosx64/thunderbird-15.0.1.en-US.mac.dmg
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] possible fix 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.
Attachment #662053 - Flags: review?(mbanner)
Attachment #662053 - Flags: review+
Attachment #662053 - Flags: approval-comm-beta+
Attachment #662053 - Flags: approval-comm-aurora+
Checked in: https://hg.mozilla.org/comm-central/rev/7c40bbbc22f0 https://hg.mozilla.org/releases/comm-aurora/rev/591830d1258c https://hg.mozilla.org/releases/comm-beta/rev/37cc1b60c8ce 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.
Assignee: nobody → m_kato
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 18.0
(In reply to Mark Banner (:standard8) from comment #10) > Checked in: > > https://hg.mozilla.org/comm-central/rev/7c40bbbc22f0 > https://hg.mozilla.org/releases/comm-aurora/rev/591830d1258c > https://hg.mozilla.org/releases/comm-beta/rev/37cc1b60c8ce > > 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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: