User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9a1) Gecko/20050911 SeaMonkey/1.1a Build Identifier: Thunderbird 1.0+, Copyright (c) 2005 mozilla.org It seems everytime the 'compact folder' option is performed, thunderbird crashes for me. See stack attached Reproducible: Always Steps to Reproduce: 1. Delete some emails 2. Compact folder 3. Actual Results: Crash
Created attachment 196760 [details] Stack trace on Mac OSX Note, this is not Sun specific. Happening on all os'es. Changing platform appropriately and upping severity
Severity: major → critical
OS: Solaris → All
Hardware: Sun → All
what thunderbird build are you running? Do you have the folder configured for offline use? Are you doing "Compact this folder" or file | compact folders?
Under Solaris Mail->News menu item (built from CVS) it shows version 1.0+ (20050810). On OS X it is version 1.0.6. I'm doing File->Compact folders, and I don't have any offline folders.
Mitch, can you tell in the debugger if m_mdbStore is null? Do you have tbird set to check imap folders other than the inbox for new messages? Or is it the inbox that you're deleting messages from?
Assignee: mscott → bienvenu
Status: UNCONFIRMED → NEW
Ever confirmed: true
Yes to both. About 15 other folders are checked, and I am mostly deleting messages from the inbox. I can't easily get to m_mdbStore sice we're quite late into the function (0x50) and it's not passed in as an argument as far as i can see. I'm rebuilding with full debugging now to get a more precise stack.
m_mdbStore is a member of nsMsgDatabase, so you should be able to get to it from *this, assuming you can get to *this.
Unfortunately i'm in C++ demangling hell tring to get to the nsMsgDatabase variable since it's also a class ;-( Will have to wait till i get a new debug crash with full source and debugging compiled up David...
perhaps it would be easier to just add these two lines to the top of nsMsgDatabase::GetTableCreateIfMissing() if (!m_mdbStore) return NS_ERROR_FAILURE; and see if the crash goes away or moves. - David
Summary: Thunderbird crashes reproduceably when compacting folder (stack attached) → Thunderbird crashes reproduceably when compacting folder [@ nsMsgDatabase::GetTableCreateIfMissing]
Sorry David, i'm unable to do any testing (recompiling) due to bug 307041 The severity of that needs to be raised to blocker since no more compilations on Solaris are possible for me at least.
*** Bug 292171 has been marked as a duplicate of this bug. ***
Mitch, can you try what David suggested in comment 9 now that the compilation issue has been fixed?
Rebuilding cvs today and applying David's suggestion. Will update bug today/tomorrow at latest.
Guys, i can't repoduce this anymore with yesterday's cvs build. Am closing for now. Will reopen if i can reproduce again with the same stack.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID
(In reply to comment #14) > Guys, i can't repoduce this anymore with yesterday's cvs build. Am closing for > now. Will reopen if i can reproduce again with the same stack. > I reguarly see an unexpect quit on OS X with both Moz 1.7.12 and SM 1.0 if we use the File / Compact option. Our IMAP accounts have 10,000s of emails spread across 100s of folders. Much of this is done at the server with folders shared between accounts. The unexpected quits occur way over 1/2 of the time. More likely 90% or more of the time. If you use the contextual menu on a particular folder all is fine.
I checked in a fix for this crash on the trunk and 1.8 branch as well yesterday. see bug 332119
Bienvenu in comment #16 > I checked in a fix for this crash on the trunk and 1.8 branch as well > yesterday. see bug 332119 David, bug 332119 does not mention compact. so WRT bug 332119 are you referring to ... comment 15, or mitch's problem/this bug (in which case a dupe is appropriate?)?
The problem fixed in bug 332119 was a core problem (i.e., handling a certain class of errors opening a db) - different user operations could expose the problem, but the stacks were all the same, so I think I'll mark this a dup.
Resolution: INVALID → DUPLICATE
Duplicate of bug: 322119
paste is our friend :) -> bug 332119 bug 278208 might also be a dup, but there is no stack and reporter is gone. Ole Holm might test it.
Duplicate of bug: 332119
Crash Signature: [@ nsMsgDatabase::GetTableCreateIfMissing]
You need to log in before you can comment on or make changes to this bug.