Thunderbird crash on exit [@ morkMap::CloseMap()]

RESOLVED FIXED

Status

Thunderbird
General
--
critical
RESOLVED FIXED
11 years ago
7 years ago

People

(Reporter: tonymec, Assigned: Bienvenu)

Tracking

({crash, fixed1.8.1.8})

x86
All
crash, fixed1.8.1.8
Bug Flags:
blocking1.8.1.5 -

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments, 1 obsolete attachment)

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)
Keywords: crash
Version: unspecified → 2.0
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
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
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?
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

11 years ago
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: blocking1.8.1.5? → blocking1.8.1.5-
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).
Created attachment 275532 [details]
Thunderbird extension, which uses nsMsgDBThreadEnumerator heavily, which causes crashes
(Assignee)

Comment 10

11 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

11 years ago
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.
(Assignee)

Comment 12

11 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

11 years ago
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 #275683 - Attachment is obsolete: true
Attachment #276680 - Flags: superreview?(mscott)

Updated

11 years ago
Attachment #276680 - Flags: superreview?(mscott) → superreview+
(Assignee)

Comment 14

11 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
Last Resolved: 11 years ago
Resolution: --- → FIXED
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

11 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?
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 19

11 years ago
Comment on attachment 276680 [details] [diff] [review]
possible fix

a=mscott
Attachment #276680 - Flags: approval1.8.1.8? → approval1.8.1.8+
(Assignee)

Comment 20

11 years ago
fix landed for 1.8.1.8
Keywords: fixed1.8.1.8
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.
Crash Signature: [@ morkMap::CloseMap()]
You need to log in before you can comment on or make changes to this bug.