90253 - N610, M092 crashes deleting folders [@ nsMsgDatabase::GetThreadForSubject]

Status: VERIFIED FIXED

(MailNews Core :: Database, defect)

Description

[greer]

The M092 topcrash report is showing this signature with the following comments 
and stack:

(32639771) Comments: Deleting a non-empty  folder in mail window's folder pane.
(32388615) Comments: Emptying local trash folder

Stack Trace: 

         nsMsgDatabase::GetThreadForSubject
[d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsMsgDatabase.cpp  line 3171]
         nsMsgDatabase::ThreadNewHdr
[d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsMsgDatabase.cpp  line 3232]
         nsMsgDatabase::AddNewHdrToDB
[d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsMsgDatabase.cpp  line 2554]
         nsMsgMailboxParser::PublishMsgHeader
[d:\builds\seamonkey\mozilla\mailnews\local\src\nsParseMailbox.cpp  line 351]
         nsMsgMailboxParser::HandleLine
[d:\builds\seamonkey\mozilla\mailnews\local\src\nsParseMailbox.cpp  line 415]
         nsMsgLineBuffer::ConvertAndSendBuffer
[d:\builds\seamonkey\mozilla\mailnews\base\util\nsMsgLineBuffer.cpp  line 218]
         nsMsgLineBuffer::BufferInput
[d:\builds\seamonkey\mozilla\mailnews\base\util\nsMsgLineBuffer.cpp  line 191]
         nsMsgMailboxParser::ProcessMailboxInputStream
[d:\builds\seamonkey\mozilla\mailnews\local\src\nsParseMailbox.cpp  line 272]
         nsMsgMailboxParser::OnDataAvailable
[d:\builds\seamonkey\mozilla\mailnews\local\src\nsParseMailbox.cpp  line 74]
         nsMailboxProtocol::ReadFolderResponse
[d:\builds\seamonkey\mozilla\mailnews\local\src\nsMailboxProtocol.cpp  line 503]
         nsMailboxProtocol::ProcessProtocolState
[d:\builds\seamonkey\mozilla\mailnews\local\src\nsMailboxProtocol.cpp  line 663]
         nsMsgProtocol::OnDataAvailable
[d:\builds\seamonkey\mozilla\mailnews\base\util\nsMsgProtocol.cpp  line 243]
         nsOnDataAvailableEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamListenerProxy.cpp  line 
185]
         PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  
line 591]
         PL_ProcessPendingEvents        
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line
524]
         _md_EventReceiverProc  
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 1072]
         KERNEL32.DLL + 0x2222f (0xbff9222f)
         0x00688b60
    nsMsgDatabase::GetThreadForSubject 73950003
        
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/mailnews/db/msgdb/src/nsMsgD
atabase.cpp line 3171

Comment 1

[greer]

cc'ing talkback. adding keywords

Comment 2

[David :Bienvenu]

potential fix checked in. will need to keep monitoring talkback to see if the
crash moves to another function, or worse, stays here.

Comment 3

[fenella]

I verifying this bug using the comments.  No longer crash.
Win32 (2001-07-27-00-0.9.2)
Win32 (2001-07-30-10 trunk.

Comment 4

[greer]

Looks like this one is rising from the dead. Talkback shows 149 incidents with 
this stack on these platforms:

   2 Windows 95  4.0 build 67109814
   1 Windows 95  4.0 build 67109975
   8 Windows 98  4.10 build 67766222
  40 Windows 98  4.10 build 67766446
  28 Windows 98  4.90 build 73010104 (WinME)
  12 Windows NT  4.0 build 1381
  28 Windows NT  5.0 build 2195 (W2K Pro)

Reopening.

Comment 5

[greer]

Attachment: Talkback user comments

Comment 6

[Blake Ross]

bienvenu, any update to this? I constantly encounter it.

Comment 7

[David :Bienvenu]

Blake, do you have steps to reproduce this bug? I have not been able to
reproduce it. Do you delete folders often? What platform are you running on?

Comment 8

[David :Bienvenu]

I think I finally understand what's going on here - people are selecting a
folder that needs to be reparsed for whatever reason (i.e., the summary file has
gotten out of date) and then either deleting the folder or emptying the trash,
causing the crash. Is that what you're doing, Blake?

Comment 9

[David :Bienvenu]

Attachment: proposed fix

Comment 10

[David :Bienvenu]

well, no answers from anyone who can recreate this, but the fix I've attached
(rs=sspitzer) makes the reparsing code a db change listener, so that if the db
gets closed out from under it, it will null out it's db pointer and gracefully
stop the reparse. We'll have to see if this gets this stack trace off the top
crash list.

Comment 11

[David :Bienvenu]

fix checked in.

Comment 12

[Sheela Ravindran]

reporter,
Can you check to see if you are crashing now after the fix was checked in.  
please comment.

Comment 13

[greer]

Not seeing this one in the data after the fix was checked in. Marking Verified.