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:126.96.36.199pre) 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 188.8.131.52-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)
12 years ago
Version: unspecified → 2.0
happened again a few minutes ago Talkback report TB31260910E Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206pre) Gecko/20070416 Thunderbird/220.127.116.11pre Build ID: 2007041603
Tb 18.104.22.168pre, 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
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.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124pre) Gecko/20070512 Thunderbird/126.96.36.199pre - Build ID: 2007051203 TB32093637E
so what was being done just prior to the crash ?
(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.
Not blocking on unconfirmed bugs.
Flags: blocking188.8.131.52? → blocking184.108.40.206-
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 220.127.116.11 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).
Created attachment 275532 [details] Thunderbird extension, which uses nsMsgDBThreadEnumerator heavily, which causes crashes
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
Created attachment 275683 [details] [diff] [review] possible fix 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.
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
Created attachment 276680 [details] [diff] [review] possible fix 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 #276680 - Flags: superreview?(mscott) → superreview+
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
Last Resolved: 12 years ago
Resolution: --- → FIXED
It's true I am unable to install my extension on trunk version. I applied the patch to Thunderbird 18.104.22.168 sources. It stopped crashing. But I know that this patch wasn't the only one of the nsMsgDatabase.cpp file since 22.214.171.124 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.
Comment on attachment 276680 [details] [diff] [review] possible fix seems to help with a shutdown crash.
Attachment #276680 - Flags: approval126.96.36.199?
12 years ago
Duplicate of this bug: 397006
(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 on attachment 276680 [details] [diff] [review] possible fix a=mscott
Attachment #276680 - Flags: approval188.8.131.52? → approval184.108.40.206+
fix landed for 220.127.116.11
Reporter: Can you please verify the bug is fixed on the latest Thunderbird nightly?
(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.
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.
(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.
You need to log in before you can comment on or make changes to this bug.