Closed
Bug 374240
Opened 17 years ago
Closed 17 years ago
Thunderbird crash on exit [@ morkMap::CloseMap()]
Categories
(Thunderbird :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: tonymec, Assigned: Bienvenu)
References
Details
(Keywords: crash, fixed1.8.1.8)
Crash Data
Attachments
(2 files, 1 obsolete file)
2.22 KB,
application/x-xpinstall
|
Details | |
4.64 KB,
patch
|
mscott
:
superreview+
mscott
:
approval1.8.1.8+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070315 SeaMonkey/1.5a Build Identifier: "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3pre) Gecko/20070315 Thunderbird/2.0pre" - Build ID: 2007031503 TB30301970X Reproducible: Didn't try Actual Results: crash Expected Results: no crash Incident ID: 30301970 Stack Signature morkMap::CloseMap() a5161d4f Product ID Thunderbird2 Build ID 2007031503 Trigger Time 2007-03-16 10:47:25.0 Platform LinuxIntel Operating System Linux 2.6.18.8-0.1-default Module thunderbird-bin + (000bc422) URL visited User Comments closing Thunderbird Since Last Crash 7 sec Total Uptime 7 sec Trigger Reason SIGSEGV: Segmentation Fault: (signal 11) Source File, Line No. /builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/db/mork/src/morkMap.cpp, line 138 Stack Trace morkMap::CloseMap() [mozilla/db/mork/src/morkMap.cpp, line 138] morkRowMap::CloseRowMap() [mozilla/db/mork/src/morkRowMap.cpp, line 254] morkRowMap::CloseMorkNode() [mozilla/db/mork/src/morkRowMap.cpp, line 254] morkNode::cut_use_count() [mozilla/db/mork/src/morkNode.cpp, line 566] morkNode::CutStrongRef() [mozilla/db/mork/src/morkNode.cpp, line 587] morkNode::SlotStrongNode() [mozilla/db/mork/src/morkNode.cpp, line 483] morkTable::CloseTable() [mozilla/db/mork/src/morkTable.cpp, line 188] morkTable::CloseMorkNode() [mozilla/db/mork/src/morkTable.cpp, line 254] morkTable::~morkTable() [mozilla/db/mork/src/morkTable.cpp, line 240] morkObject::Release() [mozilla/db/mork/src/morkObject.cpp, line 67] nsCOMPtr_base::~nsCOMPtr_base() [mozilla/xpcom/build/nsCOMPtr.cpp, line 81] nsMsgDBEnumerator::~nsMsgDBEnumerator() [mozilla/mailnews/db/msgdb/src/nsMsgDatabase.cpp, line 2625] nsMsgDBEnumerator::Release() [mozilla/mailnews/db/msgdb/src/nsMsgDatabase.cpp, line 2627] XPCJSRuntime::GCCallback() [mozilla/js/src/xpconnect/src/xpcjsruntime.cpp, line 587] DOMGCCallback() [mozilla/dom/src/base/nsJSEnvironment.cpp, line 2272] js_GC() [mozilla/js/src/jsgc.c, line 3158] JS_GC() [mozilla/js/src/jsapi.c, line 1884] nsXREDirProvider::DoShutdown() [mozilla/toolkit/xre/nsXREDirProvider.cpp, line 683] ScopedXPCOMStartup::~ScopedXPCOMStartup() [mozilla/toolkit/xre/nsAppRunner.cpp, line 740] XRE_main() [mozilla/toolkit/xre/nsAppRunner.cpp, line 2743] main() [mozilla/mail/app/nsMailApp.cpp, line 63] libc.so.6 + 0x15f9c (0xb7277f9c)
Reporter | ||
Comment 1•17 years ago
|
||
happened again a few minutes ago Talkback report TB31260910E Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4pre) Gecko/20070416 Thunderbird/2.0.0.0pre Build ID: 2007041603
Reporter | ||
Comment 2•17 years ago
|
||
Tb 2.0.0.4pre, build 2007042003, incident TB31410500Y see also http://talkback-public.mozilla.org/search/start.jsp?search=1&searchby=stacksig&match=contains&searchfor=morkMap%3A%3ACloseMap&vendor=MozillaOrg&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid&rlimit=500 42 crashes to date on Linux and Win32, the oldest one is incident 28925231 but the oldest build seems to be 2006120418 (W32, incident 29282679 ). No Mac incidents that I can see.
OS: Linux → All
Reporter | ||
Comment 3•17 years ago
|
||
several versions of Fx & Tb (1.5, 2.0 & trunk) seem to be involved. I'm leaving this at Tb2 (PC/All) for the time being but feel free to requalify it if the talkback reports seem to point in another direction.
Flags: blocking1.8.1.5?
Reporter | ||
Comment 4•17 years ago
|
||
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4pre) Gecko/20070512 Thunderbird/2.0.0.4pre - Build ID: 2007051203 TB32093637E
Comment 5•17 years ago
|
||
so what was being done just prior to the crash ?
Reporter | ||
Comment 6•17 years ago
|
||
(In reply to comment #5) > so what was being done just prior to the crash ? > That last crash was almost a month ago. As far as I can remember, the last thing I did before the crash was to hit Ctrl-Q.
Comment 7•17 years ago
|
||
Not blocking on unconfirmed bugs.
Flags: blocking1.8.1.5? → blocking1.8.1.5-
Comment 8•17 years ago
|
||
I think, I can confirm this bug. It appears during (for example) ~nsMsgDBThreadEnumerator. SEGFAULT goes from morkMap and morkArray, which both use orkinHeap, which inherits from nsIMdbHeap (morkMap->heap & morkArray->mArray_Heap). src: morkMap.cpp, morkArray.cpp, orkinHeap.cpp Memory is already corrupted at ::CloseMorkNode. As I've looked at the memory, the corrupted vtable seems to be the reason of crashes. It does that when it tries to call for example mArray_Heap->Free(...) Normally a nsIMdbHeap object has (at its beginning) an address: 0xb385a888, then some data in an array I've added to the class. At the address: 0xb385a888 <_ZTV9orkinHeap+8> [some data] (I've modified classes, so offsets might differ) When a SEGFAULT comes up, the address to the vtable (normally 0xb385a888) is NULLed. I didn't manage to track down the moment of NULLing. For tests I use self-compiled Thunderbird 2.0.0.6 on Ubuntu. I attach an extension I've made. It uses nsMsgDBThreadEnumerator heavily, so it crashes the application quite often. Just click a lot and quickly at newsgroups (folder tree).
Comment 9•17 years ago
|
||
Assignee | ||
Comment 10•17 years ago
|
||
the problem is that the db is closed, but the db enumerator doesn't know about it. I think the enumerator just has to be a db listener, and clear out its member vars when the db is closed. Or, the db could just have a flag that says its closed, which means the enumerator shouldn't use its pointers into the db object. Or, the db could just keep track of the enumerators it has handed out, and clear their member vars when the underlying mork db is closed. That might be the simplest.
Assignee: mscott → bienvenu
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 11•17 years ago
|
||
I could be wrong, but I think this will help a little - we were releasing the db, before the table, but if the nsMsgDatabase object gets deleted, it will release the last reference to the store, which will cause problems when we clear the table. So the simple fix is to clear the table before releasing the db. This still won't help with the case where the DB is ForceClosed - I need to think how to deal with that.
Assignee | ||
Comment 12•17 years ago
|
||
I just noticed that patch won't help with the nsMsgDBThreadEnumerator problem in any case..I wasn't able to reproduce this problem on the Mac. I'll have to try windows, but it'll be a while before I can get to a windows box
Assignee | ||
Comment 13•17 years ago
|
||
This rearranges some of the cleanup so that we release the db last, and the object that depend on the db first, so that we don't end up with pointers into mork structures that have been deleted...
Attachment #275683 -
Attachment is obsolete: true
Attachment #276680 -
Flags: superreview?(mscott)
Updated•17 years ago
|
Attachment #276680 -
Flags: superreview?(mscott) → superreview+
Assignee | ||
Comment 14•17 years ago
|
||
fix checked in - I don't know how you'd verify this, however, since the fix is only on the trunk, and I suspect the extension doesn't work with trunk builds.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Comment 15•17 years ago
|
||
It's true I am unable to install my extension on trunk version. I applied the patch to Thunderbird 2.0.0.6 sources. It stopped crashing. But I know that this patch wasn't the only one of the nsMsgDatabase.cpp file since 2.0.0.6 until now. (http://bonsai.mozilla.org/cvsgraph.cgi?file=mozilla/mailnews/db/msgdb/src/nsMsgDatabase.cpp&rev=1.388) Thank You for the patch. Now I can only wait for a release version with the patch applied.
Assignee | ||
Comment 16•17 years ago
|
||
Comment on attachment 276680 [details] [diff] [review] possible fix seems to help with a shutdown crash.
Attachment #276680 -
Flags: approval1.8.1.8?
Reporter | ||
Comment 18•17 years ago
|
||
(In reply to comment #17) > *** Bug 397006 has been marked as a duplicate of this bug. *** > ...tentatively. If morkArray::closeArray() still crashes after the morkMap::closeMap() problem is fixed and the fix ported, let whoever gets bitten reopen bug 397006, or report a new bug.
Comment 19•17 years ago
|
||
Comment on attachment 276680 [details] [diff] [review] possible fix a=mscott
Attachment #276680 -
Flags: approval1.8.1.8? → approval1.8.1.8+
Comment 21•17 years ago
|
||
Reporter: Can you please verify the bug is fixed on the latest Thunderbird nightly?
Reporter | ||
Comment 22•17 years ago
|
||
(In reply to comment #21) > Reporter: Can you please verify the bug is fixed on the latest Thunderbird > nightly? > Hardly: I don't know how to trigger the crash; it just happens from time to time. What about letting it bake for a while? Every day I install the next Tb2 nightly. If nobody (me included) sees this bug for a while, I guess we can assume the fix worked.
Comment 23•17 years ago
|
||
Tony: Sure we can let it bake. I have been running the Tbird nightlies for a while on Mac and I have not hit this bug. Thanks for running the nightlies, we appreciate it.
Reporter | ||
Comment 24•17 years ago
|
||
(In reply to comment #23) > Tony: Sure we can let it bake. I have been running the Tbird nightlies for a > while on Mac and I have not hit this bug. Thanks for running the nightlies, we > appreciate it. > I'm running them on Linux and I've seen this crash maybe 4 times since March (see my comments above) plus once with a somewhat different stack (see dupe bug 397006). You can count on me to raise hell if I see this crash again on a later nightly. Otherwise I propose to wait some "reasonable" time and then VERIFY the fix if the crash hasn't resurfaced.
Updated•13 years ago
|
Crash Signature: [@ morkMap::CloseMap()]
You need to log in
before you can comment on or make changes to this bug.
Description
•