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)

Needs to be fixed for M5 since this is a regression from M4.

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.

Fenella had already filed a bug on delete: bug 5513. Just mark it a dup of this one. Thanks, Scott!

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

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.

This was fixed last night. It should be in today's builds.

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]

M5

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.

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.

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.

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.

clearing resolution (bug is reopened)

Adding to QA Blocker radar.

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.

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.

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

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.

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

Another question for you! Bug 5510 is this bug. Which bug do you mean?

Never mind: it's http://bugzilla.mozilla.org/show_bug.cgi?id=5676

I just pulled and built and tried this out. the crash on delete is doesn't happen any more. woo-hoo!

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

I'm still marking this fixed. See bug 5676 for that bug.

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

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.

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.

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.

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.