1. Select a msg. Click delete button. 2. Do Edit | Undo Msg. Select that same msg again. Delete it. 3. Again do Edit | Undo msg. Boooom. Crashes... Build and platform: Today's windows commercial build. Note: I'm using a IMAP account, New Moden skin, if this helps.
Stack trace: (using mozilla debug build) nsCOMPtr<nsIMsgDBHdr>::assign_assuming_AddRef(nsIMsgDBHdr * 0x04b49240) line 471 + 9 bytes nsCOMPtr<nsIMsgDBHdr>::assign_with_AddRef(nsISupports * 0x04b49240) line 849 nsCOMPtr<nsIMsgDBHdr>::operator=(nsIMsgDBHdr * 0x04b49240) line 584 nsMessage::SetMsgDBHdr(nsMessage * const 0x048865c4, nsIMsgDBHdr * 0x04b49240) line 545 nsImapMailFolder::CreateMessageFromMsgDBHdr(nsImapMailFolder * const 0x0338195c, nsIMsgDBHdr * 0x04b49240, nsIMessage * * 0x0012fa88) line 2134 nsMsgDBFolder::OnKeyAddedOrDeleted(unsigned int 25757, unsigned int 25756, int 17, nsIDBChangeListener * 0x00000000, int 1, int 1, int 1) line 691 + 52 bytes nsMsgDBFolder::OnKeyAdded(nsMsgDBFolder * const 0x033819d0, unsigned int 25757, unsigned int 25756, int 17, nsIDBChangeListener * 0x00000000) line 673 nsMsgDatabase::NotifyKeyAddedAll(nsMsgDatabase * const 0x04123230, unsigned int 25757, unsigned int 25756, int 17, nsIDBChangeListener * 0x00000000) line 505 + 28 bytes nsMsgDatabase::AddNewHdrToDB(nsMsgDatabase * const 0x04123230, nsIMsgDBHdr * 0x04b49240, int 1) line 2551 nsImapMailFolder::NormalEndHeaderParseStream(nsImapMailFolder * const 0x03381a04, nsIImapProtocol * 0x038ee670) line 2094 XPTC_InvokeByIndex(nsISupports * 0x03381a04, unsigned int 18, unsigned int 1, nsXPTCVariant * 0x04b49200) line 139 EventHandler(PLEvent * 0x04b4de60) line 508 + 41 bytes PL_HandleEvent(PLEvent * 0x04b4de60) line 589 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00f6b110) line 526 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00d60808, unsigned int 49432, unsigned int 0, long 16167184) line 1059 + 9 bytes USER32! 77e71820() 00f6b110()
Looks like Windows only bug. Adding crash keyword.
looks related to the compact folders problem - because the msMessage resources are leaking...
Yes it does look like that crash. We really need to find this leak.
I'll look at this.
this is a ref-counting problem of some sort - the nsMsgDBHdr is getting deleted, even though the nsMessage is holding onto a reference. It might be a ref-counting problem in header deleting.
good find, Suresh! This is a little complicated, but it was a problem with the header caching code - headers only get cached when they get retrieved from a db, not when they get added to a db, but we thought they were cached and released them to account for the ref the cache held...anyway, I have a fix.
fix checked in.
I'll just mark nsbeta3+ for the heck of it :-)
OK using sep 08 commercial build NT 4.0 and linux rh6.0. No mac build yet, assume OK on mac.