TB09 Crash when quitting Thunderbird [@ nsMsgDatabase::~nsMsgDatabase]



14 years ago
9 years ago


(Reporter: marcia, Assigned: Scott MacGregor)


({crash, fixed-aviary1.0, topcrash})

Firefox Tracking Flags

(Not tracked)


(crash signature)


(1 attachment)

Seen using Tbird nightly 2004-11-03-12-0.9


1. Smoketesting the build, doing a lot of manipulation with Virtual Folders. The
last thing I remember operating on before the crash was virtual folders,
specifically deleting a virtual folder.

2. Quit Firefox, and then got this crash:


dbaron suggested it might be worthwhile to file this bug.
Created attachment 164499 [details] [diff] [review]
some bulletproofing of the CleanupCache hack

This patch (untested) has a little bulletproofing of the CleanupCache hack. 
It's really only the change of the release loop to a refcount-stabilization
plus deletion that should change everything -- the rest should just be cleanup.
 (I replaced the nsCOMPtr kungFuDeathGrip with manual AddRef / Release and then
used the refcount returned from release instead of FindInCache.  And I removed
an unneeded nsCOMPtr that couldn't even serve any "death grip" purpose since
there's a manual AddRef / Release around the whole function.)

bienvenu may be working on a better fix, though.
And, for the record, the stack is:

line 893]
line 964]
line 761]
[/builds/thunderbird-release/0.9/mozilla/xpcom/glue/nsGenericFactory.cpp, line 249]
line 60]
[/builds/thunderbird-release/0.9/mozilla/xpcom/ds/pldhash.c, line 345]
line 35]
line 895]
[/builds/thunderbird-release/0.9/mozilla/xpcom/build/nsXPComInit.cpp, line 823]
[/builds/thunderbird-release/0.9/mozilla/toolkit/xre/nsAppRunner.cpp, line 784]
[/builds/thunderbird-release/0.9/mozilla/toolkit/xre/nsAppRunner.cpp, line 1936]
_start()   start()

(and the missing frame is most likely because gcc does tail-call optimization on
the module destructor in mailnews/db/msgdb/build/nsMsgDBFactory.cpp)


14 years ago
Severity: normal → critical

Comment 3

14 years ago
This happens to me reliably, about 98% of the time I exit Thunderbird.  I just
repo'd it with the following steps:

1) Open Thunderbird.
2) Close Thunderbird by clicking the X in the control box.
3) Send trackback.

I'm using TB 0.9 on Windows XP.
Summary: Crash when quitting Thunderbird → Crash when quitting Thunderbird [@ nsMsgDatabase::~nsMsgDatabase]


14 years ago
Attachment #164499 - Flags: review?(bienvenu)

Comment 4

14 years ago
are there reproducible steps to recreate this? It doesn't make sense to me how
this could happen and I'd like to fix the root cause...

Comment 5

14 years ago
David: When I initially crashed, I am not 100% sure of how it happened. I know
that I don't see the behavior in Comment #3, but I am using Tbird on a Mac.
Since that crash, I have not crashed again on Thunderbird despite using it on a
daily basis.

Comment 6

14 years ago
I can do this reliably:

1. Open Thunderbird.
2. Close Thunderbird (control box X or File->Exit).
3. Crash.

I have about 5 pop accounts, no live folders, and maybe 4 RSS feeds.  One of the
RSS feeds is protected by http auth.  I have a few (maybe 5) to filter mail into
folders based on subject lines.

I'd be happy to help diagnose in whatever way with logs, or whatever.

Comment 7

14 years ago
Runako, do you have talkback installed? Do talkback reports get filed?

Comment 8

14 years ago
Comment on attachment 164499 [details] [diff] [review]
some bulletproofing of the CleanupCache hack

we can try this and see if it reduces the crashes from talkback...
Attachment #164499 - Flags: superreview+
Attachment #164499 - Flags: review?(bienvenu)
Attachment #164499 - Flags: review+

Comment 9

14 years ago
Adding topcrash keyword to keep this on the radar.  It might be related to or a
dup of another close crash on Win32: bug 269571
Keywords: topcrash


14 years ago
Summary: Crash when quitting Thunderbird [@ nsMsgDatabase::~nsMsgDatabase] → TB09 Crash when quitting Thunderbird [@ nsMsgDatabase::~nsMsgDatabase]

Comment 10

14 years ago
patch checked in on trunk and branch - we'll monitor talkback to see if it's fixed.
Last Resolved: 14 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
this might be the same as the crash-on-quit (in tbird) that I occaisionally see
on linux.

OS: MacOS X → All
Hardware: Macintosh → All
That stack looks different.

Comment 13

14 years ago
sairuh that was the crash bug that was in builds from Monday, Tuesday and
Wednesday of this past week. David fixed that issue. It was a code regression. 

Comment 14

14 years ago
I do have talkback installed.  I sent a few talkback reports after this crash.

However, for whatever reason I can no longer repro this at all.  The only
configuration changes that I can remember are: 1) upgrade Firefox to 1.0 final
and 2) removed basic auth protected feed from thunderbird and 3) installed
Konfabulator for Windows.  Not sure if either of these specifically fixed the
problem, but it looks like my system isn't a good candidate for helping out
anymore here.  Sorry, I'll check back in if it happens again.

Comment 15

14 years ago
*** Bug 269571 has been marked as a duplicate of this bug. ***

Comment 16

10 years ago
TB trunk (3.x) crashes when exiting due to the patch of this bug.
I filed a bug 464419.  I don't understand following snippet:

+          // The destructor may cause the remaining references to be
+          // released, so stabilize the refcount and then manually
+          // delete.
+          ++pMessageDB->mRefCnt;
+          delete pMessageDB;

I think the memories pointed by pMessageDB are invalid any more after deleting.
if so,
1. Why we do "++" operation before deleting?

2. nsCOMPtr<nsIMsgDatabase> m_backupMailDB of class nsParseMailMessageState
   points to the same object as pMessageDB and ~nsParseMailMessageState() is called later.
   So when ~nsCOMPtr<nsIMsgDatabase>() is called to destruct m_backupMailDB, 
   TB will access the memory which is already freed by "delete pMessageDB". 
   Crash occurs.
Crash Signature: [@ nsMsgDatabase::~nsMsgDatabase]
You need to log in before you can comment on or make changes to this bug.