353915 - Deleting attachments from messages crashes SM (regression)

Status: RESOLVED FIXED

(MailNews Core :: Attachments, defect)

Description

[Robert Roessler]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060921 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060921 SeaMonkey/1.5a

As of the 2006092009 nightly SM trunk build (and possibly up to a week earlier), the ability to Delete (or Delete All) attachments has been lost - SM now does a "we want to phone this home to Microsoft" crash in msgbase.dll.  There is no apparent corruption to the email files, and rebuilding the summary files does not change the behavior.  I note that the appearance of this bug seemed to coincide with the fixing of bug 351685, which dealt with compacting email files and reporting results from the summary information.

Reproducible: Always

Steps to Reproduce:
1. Select an attachment from Inbox/Sent and request Delete from its context menu.
2. Confirm the delete and watch crash happen.
3.

Actual Results:  
Crash in msgbase.dll - XP wants to notify Microsoft about it.

Expected Results:  
Attachment gets deleted quietly.

Windows nightly installer(s) from nightly/latest-trunk directory running on XP SP2.

Comment 1

[Adam Guthrie]

Do we have Talkback for these builds? If so, getting an ID would be helpful. http://kb.mozillazine.org/Talkback

Comment 2

[Robert Roessler]

(In reply to comment #1)
> Do we have Talkback for these builds? If so, getting an ID would be helpful.
> http://kb.mozillazine.org/Talkback

I do not use Talkback - would it be useful for an OS-detected error (rather than an internal SM-detected failure)?  If so, I can reinstall with Talkback enabled.

Comment 3

[Andrew Schultz]

This regressed between linux seamonkey builds 2006-09-15-08-trunk and 2006-09-16-08-trunk, although I don't see anything relevant there.

Comment 4

[Andrew Schultz]

Attachment: stack

(gdb) frame 6
2775      mMsgFileSpec->CloseStream();
(gdb) p mMsgFileSpec
$1 = {mRawPtr = 0x0}

Comment 5

[Andrew Schultz]

This is bustage from bug 351920.  ispiked noted on IRC that the patch removed the initialization of mMsgFileSpec (it makes an nsIFile now and then drops it).

Comment 6

[Andrew Schultz]

Attachment: use the nsIFile instead

Comment 7

[David :Bienvenu]

Comment on attachment 239761 [details] [diff] [review]
use the nsIFile instead

thx for the fix!

Comment 8

[Andrew Schultz]

FIXED

Comment 9

[Dieter Issler]

SeaMonkey 1.0.5 de-AT on SuSE Linux 9.2 i686:
Mailer: Selecting "Alle löschen" ("Delete all") from popup menu in Attachments panel crahses the application reproducibly, at least for certain messages.

Some investigation showed the problem to be a little tricky:

If I select "Alle speichern" ("Save all"), I get the message that the attachments could not be saved.
If I try to save the attachments one by one, in a recent case of the problem, two attachments could be saved without any problems but two others could not. The progress window opens after the command has been given and the target directory selected, but there is no progress.

It seems the problem is that I in fact succeeded in detaching the attachments in my first attempt, but the Attachments panel does *not* show they were detached! When I checked the source text of the message, I found the attachments to have been detached: X-Mozilla-Altered: AttachmentDetached; date="Wed Sep 27 09:33:34 2006". In the meantime, two of the detached files were renamed---they are the ones that could not be saved. the more serious part is that SeaMonkey crashes if it cannot find all the attachments to save in a "Save all" command.

Naive sugestion: for my use it would be fully sufficient if SeaMonkey just showed that the attachments have been detached; if it can tell me where they were stored, that would be even better. But it need not give me the opportunity any more to save, detache or delete them.

Having said all this, I wish tomention that I am very happy that the option of detaching or deleting attachments now exists---I missed it very much in earlier versions!