12295 - [Dogfood] Deleting messages crashes and doesn't reset selection.

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[scottputterman]

Open Mail 3 pane.
Select a folder
Select a message.
Delete the message.
Select another message.
Using tree.selectedItems, I get a list of 2 items.  After deleting the first
message it appears as if the selectedItem list was not reset.

Comment 1

[David Hyatt]

This could get nasty if we're leaking content nodes at all.  The right way to do
this is for me to remove the object from the selection when the node goes away,
but if we leak, this will never happen.

I'll go ahead and try adding the logic for this and cross my fingers.

Comment 2

[David Hyatt]

Should be fixed.

Comment 3

[scottputterman]

I'm pretty sure I pulled and built the correct changes.  I'll do a full build
now to make sure.  Now when I delete a message I get the following precondition:

"You can't dereference a NULL nsCOMPtr with operator*()."

nsCOMPtr<nsIContent>::operator->() line 604 + 34 bytes
nsXULTreeElement::FireOnSelectHandler() line 314 + 35 bytes
RDFElementImpl::RemoveChildAt(RDFElementImpl * const 0x03829980, int 6, int 1)
line 1944
RDFGenericBuilderImpl::RemoveWidgetItem(nsIContent * 0x02fc3150, nsIRDFResource
* 0x027b2150, nsIRDFResource * 0x037f48c0, int 1) line 2186 + 29 bytes
RDFGenericBuilderImpl::OnUnassert(RDFGenericBuilderImpl * const 0x02fc84d4,
nsIRDFResource * 0x030156b0, nsIRDFResource * 0x027b2150, nsIRDFNode *
0x037f48c0) line 726 + 35 bytes
CompositeDataSourceImpl::OnUnassert(CompositeDataSourceImpl * const 0x02fc8484,
nsIRDFResource * 0x030156b0, nsIRDFResource * 0x027b2150, nsIRDFNode *
0x037f48c0) line 1389
nsMessageViewDataSource::OnUnassert(nsMessageViewDataSource * const 0x027b5a18,
nsIRDFResource * 0x030156b0, nsIRDFResource * 0x027b2150, nsIRDFNode *
0x037f48c0) line 554
nsMsgRDFDataSource::unassertEnumFunc(nsISupports * 0x027b5a18, void *
0x0012faac) line 368
nsSupportsArray::EnumerateForwards(nsSupportsArray * const 0x02feb390, int
(nsISupports *, void *)* 0x012c2dd0
nsMsgRDFDataSource::unassertEnumFunc(nsISupports *, void *), void * 0x0012faac)
line 351 + 20 bytes
nsMsgRDFDataSource::NotifyObservers(nsIRDFResource * 0x030156b0, nsIRDFResource
* 0x027b2150, nsIRDFNode * 0x037f48c0, int 0) line 344
nsMsgFolderDataSource::OnItemRemoved(nsMsgFolderDataSource * const 0x027b2200,
nsIFolder * 0x030156bc, nsISupports * 0x037f48c0) line 658
nsMsgMailSession::NotifyFolderItemDeleted(nsMsgMailSession * const 0x02785760,
nsIFolder * 0x030156bc, nsISupports * 0x037f48c0) line 258
nsMsgFolder::NotifyItemDeleted(nsISupports * 0x037f48c0) line 1630
nsMsgDBFolder::OnKeyDeleted(nsMsgDBFolder * const 0x03015718, unsigned int
37008, unsigned int 0, int 0, nsIDBChangeListener * 0x00000000) line 314
nsMsgDatabase::NotifyKeyDeletedAll(nsMsgDatabase * const 0x0366e500, unsigned
int 37008, unsigned int 0, int 0, nsIDBChangeListener * 0x00000000) line 136 +
28 bytes
nsMsgDatabase::DeleteHeader(nsMsgDatabase * const 0x0366e500, nsIMsgDBHdr *
0x037f4910, nsIDBChangeListener * 0x00000000, int 1, int 1) line 1034
nsMsgLocalMailFolder::DeleteMessage(nsIMessage * 0x037f48cc,
nsITransactionManager * 0x00000000, int 1) line 1433 + 44 bytes
nsMsgLocalMailFolder::DeleteMessages(nsMsgLocalMailFolder * const 0x030156bc,
nsISupportsArray * 0x03b2a420, nsITransactionManager * 0x00000000, int 1) line
1176
DeleteMessage(nsIURI * 0x03ad0284, nsIMsgFolder * 0x030156bc) line 138 + 28
bytes
nsCopyMessageStreamListener::OnStopRequest(nsCopyMessageStreamListener * const
0x03ace270, nsIChannel * 0x03ad17e0, nsISupports * 0x03ad0284, unsigned int 0,
const unsigned short * 0x00000000) line 198 + 26 bytes

Comment 4

[David Hyatt]

Ok, I'm going to have to do some complicated stuff to dodge this. Sigh.

Comment 5

[scottputterman]

Unfortunately, this leads to a crash.  So I'm changing the severity to critical.

Comment 6

[David Hyatt]

Bad news, stud.  I can't test this since mail/news is crashing on Win98 on both
my machines.  It crashes when opened through the browser sidebar as well as in
the messenger window.

Who should I give the bug to on your end?

Comment 7

[scottputterman]

You can assign it to me.  What's the stack look like?

Comment 8

[David Hyatt]

One thing to know is that Win98 is completely screwed up right now.  There seems
to be some kind of horrible resource leak that brings down the whole machine.

Comment 9

[Roger Roberts]

I am seeing the same assertion as putterman (dereferencing null nsCOMPtr) in my
own code.  It appears to be a bad type-cast in RDFElementImpl::RemoveChildAt
(line 1960 of RDFElement.cpp):

   nsXULTreeElement* tree = (nsXULTreeElement*)(treeElement.get());

The C-style cast is wrong.  A C++ static_cast should be used instead:

  nsXULTreeElement* tree = NS_STATIC_CAST(nsXULTreeElement*,
     NS_STATIC_CAST(nsIDOMXULTreeElement*, treeElement.get()));

Comment 10

[scottputterman]

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

Comment 11

[scottputterman]

changing summary to reflect that this is a crasher.

Comment 12

[David :Bienvenu]

adding myself to cc list - I need to be able to delete a message to recreate
another problem :-(

Comment 13

[lchiang]

Marking [Dogfood] for mail.

Comment 14

[David :Bienvenu]

the change suggested by jgroberts works for me - I no longer crash when
deleting.

Comment 15

[Phil Peterson]

Bulk move mail/news M10 bugs to M11

Comment 16

[scottputterman]

It looks like this got fixed, David.  At least I can delete a message in today's
build, and I can sort after viewing a mesage which was another problem related
to this bug.

Comment 17

[Peter Trudelle]

resolving as fixed

Comment 18

[lchiang]

Esther - pls verify on other platforms.
This is working in the Win32 build 1999091508.

Comment 19

[esther]

Using 19990922 builds on win98, mac and linux, this is fixed.  Tested Delete a
message, then select another, then delete that one.  All OK.  Also tested
selecting a message then changing sort, viewing message (see comment 9/2).
There was no crash, sort worked, and so did delete.  Verified