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.
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: 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)
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]
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...
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.
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.
Runako, do you have talkback installed? Do talkback reports get filed?
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...
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
Summary: Crash when quitting Thunderbird [@ nsMsgDatabase::~nsMsgDatabase] → TB09 Crash when quitting Thunderbird [@ nsMsgDatabase::~nsMsgDatabase]
patch checked in on trunk and branch - we'll monitor talkback to see if it's fixed.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
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
OS: MacOS X → All
Hardware: Macintosh → All
That stack looks different.
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.
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.
*** Bug 269571 has been marked as a duplicate of this bug. ***
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.