309259 - Thunderbird crashes reproduceably when compacting folder [@ nsMsgDatabase::GetTableCreateIfMissing]

Status: RESOLVED DUPLICATE of bug 332119

(Thunderbird :: General, defect)

Description

[Mitch]

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

Comment 1

[Mitch]

Attachment: Stacktrace of crash

Comment 2

[Mitch]

Attachment: Stack trace on Mac OSX

Note, this is not Sun specific. Happening on all os'es. Changing platform
appropriately and upping severity

Comment 3

[David :Bienvenu]

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?

Comment 4

[Mitch]

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.

Comment 5

[David :Bienvenu]

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?

Comment 6

[Mitch]

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.

Comment 7

[David :Bienvenu]

m_mdbStore is a member of nsMsgDatabase, so you should be able to get to it from
*this, assuming you can get to *this.

Comment 8

[Mitch]

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

Comment 9

[David :Bienvenu]

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

Comment 10

[Mitch]

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.

Comment 11

[timeless]

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

Comment 12

[Scott MacGregor]

Mitch, can you try what David suggested in comment 9 now that the compilation issue has been fixed?

Comment 13

[Mitch]

Rebuilding cvs today and applying David's suggestion. Will update bug today/tomorrow at latest.

Comment 14

[Mitch]

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.

Comment 15

[David Ross]

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

Comment 16

[David :Bienvenu]

I checked in a fix for this crash on the trunk and 1.8 branch as well yesterday. see bug 332119

Comment 17

[Wayne Mery (:wsmwk)]

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?)?

Comment 18

[David :Bienvenu]

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.

Comment 19

[Wayne Mery (:wsmwk)]

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.