[PP]Application crashes when moving message to another folder

VERIFIED FIXED in M5

Status

P3
major
VERIFIED FIXED
20 years ago
11 years ago

People

(Reporter: fenella, Assigned: scottputterman)

Tracking

Trunk
All
Solaris

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: waiting for bug 5676 to be fixed before we can verify.)

(Reporter)

Description

20 years ago
RE: Seamonkey win32 build(1999-04-26-08) and linux (1999-04-26-08)
Steps:
1. Run apprunner
2. Open mail application using Tasks|messenger
3. Select a message from the Inbox folder
4. From Messenger, select "Message|Move message" and move msg to Draft or any
folder, application immediately crashes.
Occurs in win_nt 4.0 and Linux 2.0 consistently.

Error msg from Linux:
MenuItem::MenuItemSelected
mailbox://DraftsnsMsgAppCore::SetWindow(): Getting the webShell of interest...
HandleDOMEvent calledSegmentation fault (core dumped)

Updated

20 years ago
Summary: Application crashes when moving message to another folder → Application crashes when moving message to another folder

Comment 1

20 years ago
Needs to be fixed for M5 since this is a regression from M4.
(Assignee)

Updated

20 years ago
Assignee: phil → putterman
(Assignee)

Updated

20 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 2

20 years ago
this also happens when you delete a message.  The delete part is causing both
bugs, so there's no need to file a bug on that as well.

Comment 3

20 years ago
Fenella had already filed a bug on delete:  bug 5513.  Just mark it a dup of
this one. Thanks, Scott!
(Assignee)

Comment 4

20 years ago
*** Bug 5513 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 5

20 years ago
I just checked in the fix that will prevent this from crashing.  However, it
will now just do nothing.  Chris Waterson is going to check in a fix that will
fix this.  Though, even if he does fix this, this bug is occurring because I
can't handle the case where a message is created without a folder or
nsIDBMsgHdr.  I need to have a way to create these on the fly instead of
expecting them to always exist.
(Assignee)

Updated

20 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
(Assignee)

Comment 6

20 years ago
This was fixed last night.  It should be in today's builds.
(Reporter)

Updated

20 years ago
Status: RESOLVED → REOPENED
Summary: Application crashes when moving message to another folder → [PP]Application crashes when moving message to another folder
(Reporter)

Comment 7

20 years ago
RE: win32 build (1999-04-27-08)
Moving message to another folder and deleting message no longer causes
application to crash any more.
But...
On Linux build (1999-04-27-08)
Both deleting and moving message to another folder still crashes.
Reopen this bug and change it [PP]

Updated

20 years ago
Target Milestone: M5

Comment 8

20 years ago
M5
(Assignee)

Comment 9

20 years ago
Purify helped me find this one.

David, I think the problem is happening in nsMsgDatabase::DeleteHeader where you
have

	NS_RELEASE(msg);	// even though we're deleting it from the db,
need to Release.

You release without ever addref'ing.  Then when I release in my function (which
is happening because I'm an nsCOMPtr and I have to release when I go out of
scope, we have a problem because we're deleting freed memory.

Anyway, I coudl remove the nsCOMPtr and not release, but I don't think you
should be releasing. This would affect other code in nsMsgDatabase which is
depending upon you calling release.

The options I see are:

Remove this line and make the other code that depends on it release the header.
Remove this line and have the memory leaks
Keep this line and get rid of nsCOMPtr and don't release.
(Assignee)

Comment 10

20 years ago
I need to work on this tomorrow.  I'm having trouble reproducing what I wrote
above on my machine at home and now I need to pull a bunch of stuff to be able
to compile.  So, this isn't going to make it by midnight.

Comment 11

20 years ago
You're right, Scott - we should just change the two places that call
DeleteHeader without releasing the header to do their own release and remove it
from here. DeleteHeader has always worked this way, but the ref-counting
semantics have changed, I guess.
(Assignee)

Comment 12

20 years ago
I still can't reproduce this on my machine at home.  But I'm seeing other
strange refcounting problems related to deleting.  I need to spend some time on
this today.  My guess is that changing DeleteHeader in nsMsgDatabase will be
part of the changes.

Updated

20 years ago
QA Contact: 4080 → 4104
Resolution: FIXED → ---

Comment 13

20 years ago
clearing resolution (bug is reopened)

Updated

20 years ago
Whiteboard: QA BLOCKER

Comment 14

20 years ago
Adding to QA Blocker radar.
(Assignee)

Updated

20 years ago
Status: REOPENED → RESOLVED
Last Resolved: 20 years ago20 years ago
Resolution: --- → FIXED
(Assignee)

Comment 15

20 years ago
Thanks to some help with Seth we were able to track this down.  I checked in the
fix on 4/28. It shouldn't crash anymore.

A couple of notes:

1.  Sorting or changing the view followed by a delete or move won't work.  It
won't crash but it won't work.  So you can only delete before doing this.  This
has been ok'd to be put off until M6.

2.  The Move menu isn't working right now.  Alec is working on integrating his
account code into that menu.

Comment 16

20 years ago
When verifying the bug fix, also need to verify bug 5510 (delete message causes
crash) that putterman says is the same cause as this bug.
(Assignee)

Comment 17

20 years ago
Oops.  You won't be able to verify this bug until the move menu is fixed.
However, you can test the delete bug.

Comment 18

20 years ago
When will the move menu problem be fixed?  Also, what is the bug to track the
move menu?  I would consider that an M5 stopper to not have the move menu
functionality.
(Assignee)

Comment 19

20 years ago
So many questions!  I just filed bug #5510.  Alec is going to work on it.

Comment 20

20 years ago
Another question for you!  Bug 5510 is this bug.  Which bug do you mean?
I just pulled and built and tried this out.

the crash on delete is doesn't happen any more.

woo-hoo!
(Reporter)

Updated

20 years ago
Status: RESOLVED → REOPENED
(Reporter)

Comment 23

20 years ago
Re: win32 and Linux (1999-04-29-08) builds
From menu Message, select Move Message, no sub-menu is displayed. Looks like
the move option is disabled. Reopen bug
(Assignee)

Updated

20 years ago
Status: REOPENED → RESOLVED
Last Resolved: 20 years ago20 years ago
(Assignee)

Comment 24

20 years ago
I'm still marking this fixed.  See bug 5676 for that bug.
(Reporter)

Updated

20 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 25

20 years ago
RE: win32 and Linux builds(1999-04-29-08)
Looks like we are treating this bug the same as bug #5513 as a Delete crash bug.
All right.  I'll verify it because it does not crash upon Delete on both Linux
and win_nt 4.0
(Assignee)

Comment 26

20 years ago
Sorry, I just meant that it shouldn't be reopened because we haven't proved that
move doesn't work.  I still believe the fix is valid which is why I marked it
fixed again.  When the move menu bug is fixed, then we can safely say this bug
has been verified or reopened.

Comment 27

20 years ago
I'm going to "unverify this bug" - Here's what needs to be done:

(1) Verify that move message works.  This cannot be done until bug 5676 is
marked fixed.

(2) Verify that delete works.  This is already been verified by Fenella.

So, leave this bug "unverified" until item (1) can be verified.  Thanks.
Status: VERIFIED → REOPENED
Whiteboard: QA BLOCKER → waiting for bug 5676 to be fixed before we can verify.

Updated

20 years ago
Status: REOPENED → RESOLVED
Last Resolved: 20 years ago20 years ago

Comment 28

20 years ago
1999_05_03_17 Win32 build - M5.  Bug 5676 is still not fixed.  Folder names do
not show up under the Move Message menu item so we cannot verify this bug.

1999_05_04_08 Win32 build - M6 tip.  Folder names show up. Moving a message
works fine.

1999_05_03_17 Linux build - M5.  Folder names show up.  Moving a message works
fine.

1999_05_04_08 Linux and Mac builds - M6.  Folder names show up.  Moving a
message results in a copy.  Reference bug: 5792.

I am leaving this bug unverified until I get notification on whether we are
going to fix 5676 for M5.  If not, then I will mark this bug verified.  If so,
then I will wait until after the fix to verify.

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 29

20 years ago
Decided not worth putting in a workaround fix to bug 5676.

So for M5, moving messages (except on Win32 where move is non-functional) do not
cause a crash at all.  I'm marking this bug verified for M5.

The delete portion of this bug was verified already.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.