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

Status: RESOLVED FIXED

(Thunderbird :: General, defect)

Description

[Marcia Knous [:marcia]]

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

STR:

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:

http://talkback-reports.mozilla.org/talkback/quicksearch.jsp?search=2&type=iid&id=1711027

dbaron suggested it might be worthwhile to file this bug.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: 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.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

And, for the record, the stack is:

0xd0053db4
nsMsgDatabase::~nsMsgDatabase() 
[/builds/thunderbird-release/0.9/mozilla/mailnews/db/msgdb/src/nsMsgDatabase.cpp,
line 893]
nsMsgDatabase::Release() 
[/builds/thunderbird-release/0.9/mozilla/mailnews/db/msgdb/src/nsMsgDatabase.cpp,
line 964]
nsMsgDatabase::CleanupCache() 
[/builds/thunderbird-release/0.9/mozilla/mailnews/db/msgdb/src/nsMsgDatabase.cpp,
line 761]
nsGenericModule::Release() 
[/builds/thunderbird-release/0.9/mozilla/xpcom/glue/nsGenericFactory.cpp, line 249]
info_ClearEntry() 
[/builds/thunderbird-release/0.9/mozilla/xpcom/components/nsStaticComponentLoader.cpp,
line 60]
PL_DHashTableFinish() 
[/builds/thunderbird-release/0.9/mozilla/xpcom/ds/pldhash.c, line 345]
nsStaticComponentLoader::Release() 
[/builds/thunderbird-release/0.9/mozilla/xpcom/components/nsStaticComponentLoader.cpp,
line 35]
nsComponentManagerImpl::Shutdown() 
[/builds/thunderbird-release/0.9/mozilla/xpcom/components/nsComponentManager.cpp,
line 895]
NS_ShutdownXPCOM() 
[/builds/thunderbird-release/0.9/mozilla/xpcom/build/nsXPComInit.cpp, line 823]
ScopedXPCOMStartup::~ScopedXPCOMStartup() 
[/builds/thunderbird-release/0.9/mozilla/toolkit/xre/nsAppRunner.cpp, line 784]
xre_main() 
[/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)

Comment 3

[Runako Godfrey]

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.

Comment 4

[David :Bienvenu]

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

[Marcia Knous [:marcia]]

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

[Runako Godfrey]

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

[David :Bienvenu]

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

Comment 8

[David :Bienvenu]

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...

Comment 9

[Jay Patel [:jay]]

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

Comment 10

[David :Bienvenu]

patch checked in on trunk and branch - we'll monitor talkback to see if it's fixed.

Comment 11

[sairuh (rarely reading bugmail)]

this might be the same as the crash-on-quit (in tbird) that I occaisionally see
on linux.

http://talkback-reports.mozilla.org/talkback/quicksearch.jsp?search=2&type=iid&id=1836676

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

That stack looks different.

Comment 13

[Scott MacGregor]

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

[Runako Godfrey]

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

[David :Bienvenu]

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

Comment 16

[Boying Lu]

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.