360342 - crash delete attachment with IMAP mail [@ nsDelAttachListener::OnStopRequest]

Status: RESOLVED FIXED

(MailNews Core :: Attachments, defect)

Description

[Andrew Schultz]

With linux seamonkey build 2006-11-09-09, I crash deleting an attachment from an IMAP email.  I'll attach a stacktrace.  I won't have a chance to diagnose this further for a week.

Comment 1

[Andrew Schultz]

Attachment: stacktrace

(gdb) frame 6
#6  0x066d31ab in nsDelAttachListener::OnStopRequest (this=0xa5fa168, aRequest=0xa5cc578, aContext=0xa5e7d0c, aStatusCode=0)
    at /build/andrew/moz-debug/mozilla/mailnews/base/src/nsMessenger.cpp:2778
2778      mOriginalMessage->GetFlags(&origMsgFlags);
(gdb) p mOriginalMessage
$1 = {mRawPtr = 0x0}

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

Same for version 3 alpha 1 (20061119) on Windows. The first time this crash appears is on 2006-09-17 (TB23392259).

Talkback id: TB26213255Y

Stack Signature	 nsDelAttachListener::OnStopRequest 56c68ae3
Product ID	ThunderbirdTrunk
Build ID	2006111903
Trigger Time	2006-11-19 07:11:20.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	thunderbird.exe + (004b6b67)
URL visited	
User Comments	Deleting attachment from IMAP message crashes Thunderbird
Since Last Crash	99 sec
Total Uptime	99 sec
Trigger Reason	Access violation
Source File, Line No.	d:\builds\tinderbox\tb-trunk\winnt_5.2_depend\mozilla\mailnews\base\src\nsmessenger.cpp, line 2766
Stack Trace 	
nsDelAttachListener::OnStopRequest  [mozilla\mailnews\base\src\nsmessenger.cpp, line 2766]
nsStreamConverter::OnStopRequest  [mozilla\mailnews\mime\src\nsstreamconverter.cpp, line 1051]
XPTC_InvokeByIndex  [mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp, line 102]
nsProxyObjectCallInfo::Run  [mozilla\xpcom\proxy\src\nsproxyevent.cpp, line 181]
NS_ProcessNextEvent_P  [mozilla\xpcom\build\nsthreadutils.cpp, line 225]
nsBaseAppShell::Run  [mozilla\widget\src\xpwidgets\nsbaseappshell.cpp, line 153]
MSVCR80.dll + 0x8a21 (0x78138a21)

Comment 3

[Andrew Schultz]

erm, why did you request blocking-thunderbird2?

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

(In reply to comment #3)
> erm, why did you request blocking-thunderbird2?

Good catch. ;) But my last comment misses some more information. That does also occur for version 2 beta 1 (20061118)

Talkback: TB26213853E

Stack Signature	 nsDelAttachListener::OnStopRequest c96036d6
Product ID	Thunderbird2
Build ID	2006111803
Trigger Time	2006-11-19 07:28:55.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	thunderbird.exe + (00440843)
URL visited	
User Comments	Crash when deleting IMAP attachment
Since Last Crash	53 sec
Total Uptime	53 sec
Trigger Reason	Access violation
Source File, Line No.	e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/base/src/nsMessenger.cpp, line 2803
Stack Trace 

Comment 5

[Andrew Schultz]

this regressed between seamonkey builds 2006-11-02-10-trunk and 2006-11-03-08-trunk, indicating bug 286655.  This is a tbird topcrash on trunk and branch.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

(In reply to comment #5)
> this regressed between seamonkey builds 2006-11-02-10-trunk and
> 2006-11-03-08-trunk, indicating bug 286655.

Like I told in comment 2 the crashes happen since 2006-09-17. So it's earlier as the patch from David on bug 286655. Dunno if there is a coherance.

What I have seen is something strange. I tried to delete the attachment of a mail with Tb2 which works without a crash. Doing the same with a trunk build and afterwards with Tb2 again, it also crashes. I'll have a look at the message headers or what else could be broken.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

Ok, this crash seems to only appear for base64 encoded attachments. 7bit (text/plain) still works for Tb2 and Trunk.

If a message with such a base64 encoded attachment is opened by a Trunk build it is marked as read like expected. If I open now Tb2 and try to delete the attachment from the same message then Tb2 crashes. If the message isn't marked as read by a Trunk build deleting the attachment also works in Tb2. I will have a look at the IMAP stat files on my server if I can find a difference there.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

Attachment: testcase

testcase with base64 encoding which crashes trunk builds of Thunderbird

Comment 9

[Andrew Schultz]

> Like I told in comment 2 the crashes happen since 2006-09-17. So it's earlier
> as the patch from David on bug 286655. Dunno if there is a coherance.

For what I'm looking at, I get no crash with a 11/1 or 11/2 trunk build.

Thunderbird talkback data suggests the same signature existed from 9/16 - 9/23,
but there are no crashes between 9/23 and 11/05.

> Ok, this crash seems to only appear for base64 encoded attachments. 7bit
> (text/plain) still works for Tb2 and Trunk.

The attachment that I'm testing with is a 150K .doc file.  I see no crash with
a shorter .doc file or a ~150K .png.  So I suspect there is more to it than the
encoding.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

Same happens with MS Exchange Server 2003. After deleting an attachment the first time the message gets invisible until I reopen the folder. Then I got a hour glass cursor, Thunderbird slows down and no other message could be open. So I killed the process. The windows error reporting dialog was shown but no talkback. After starting TB again and trying to delete the next attachment Thunderbird immediately dies with the same stack trace like above. 

Comment 11

[David :Bienvenu]

I'm not seeing a crash on windows, with a 2.0 build and the attached test case.

Comment 12

[Robert Kaiser]

OK, opening the testcase of this bug in a message window, forwarding it to an IMAP account, and trying to delete the attachment there caused the crash for me on a SeaMonkey 1.8 branch build from today (Linux, GTK2), while it still worked on a build from a month ago.
The crash happens before actually deleting the attachment, as after launching SeaMonkey again, the attachment is still there. Deleting a large image attachment from a different mail in the same IMAP inbox worked correctly though.

Comment 13

[David :Bienvenu]

I'll try that, and I'll try it on the mac...

Comment 14

[Magnus Melin [:mkmelin]]

Branch regression window is also 2006-11-02 -> 2006-11-03.

Comment 15

[David :Bienvenu]

yes, I'm pretty sure the fix for bug 286655 caused the regression, but I still can't reproduce the problem.

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

Stack trace on Linux is a bit different. It references another line inside nsmessenger.cpp

Stack Signature	 nsDelAttachListener::OnStopRequest() 02932927
Product ID	Thunderbird2
Build ID	2006112903
Trigger Time	2006-11-30 10:18:01.0
Platform	LinuxIntel
Operating System	Linux 2.6.15-27-386
Module	thunderbird-bin + (00772a50)
URL visited	
User Comments	testing testcase for topcrash in bug360342
Since Last Crash	1 sec
Total Uptime	1 sec
Trigger Reason	SIGSEGV: Segmentation Fault: (signal 11)
Source File, Line No.	/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/mailnews/base/src/nsMessenger.cpp, line 848
Stack Trace 	
nsDelAttachListener::OnStopRequest()  [mozilla/mailnews/base/src/nsMessenger.cpp, line 848]
nsStreamConverter::OnStopRequest()  [mozilla/mailnews/mime/src/nsStreamConverter.cpp, line 1051]
nsOnStopRequestEvent0::HandleEvent()  [mozilla/netwerk/base/src/nsAsyncStreamListener.cpp, line 713]
nsStreamListenerEvent0::HandlePLEvent()  [mozilla/netwerk/base/src/nsAsyncStreamListener.cpp, line 122]
PL_HandleEvent()  [mozilla/xpcom/threads/plevent.c, line 688]
PL_ProcessPendingEvents()  [mozilla/xpcom/threads/plevent.c, line 623]
nsEventQueueImpl::ProcessPendingEvents()  [mozilla/xpcom/threads/nsEventQueue.cpp, line 421]
event_processor_callback()  [mozilla/widget/src/gtk2/nsAppShell.cpp, line 71]
libglib-2.0.so.0 + 0x4a52c (0xb793152c)
libglib-2.0.so.0 + 0x238d6 (0xb790a8d6)
libglib-2.0.so.0 + 0x26996 (0xb790d996)
libglib-2.0.so.0 + 0x26cb8 (0xb790dcb8)
libgtk-x11-2.0.so.0 + 0x11e765 (0xb7bb9765)
nsAppShell::Run()  [mozilla/widget/src/gtk2/nsAppShell.cpp, line 141]
nsAppStartup::Run()  [mozilla/toolkit/components/startup/src/nsAppStartup.cpp, line 152]
XRE_main()  [mozilla/toolkit/xre/nsAppRunner.cpp, line 848]
main()  [mozilla/mail/app/nsMailApp.cpp, line 63]
libc.so.6 + 0x14ea2 (0xb739bea2)

Comment 17

[David :Bienvenu]

I'm still unable to reproduce this...will keep trying.

If it's crashing in nsDelAttachListener::OnStopRequest, it hasn't even got to the part where it uploads the message to the server - it's just finished streaming the message.

Comment 18

[Karsten Düsterloh]

I can reproduce this with a custom SM trunk debug Mac/PPC build of 2006-12-03.
The crashing code is mOriginalMessage = 0x0 in nsMessenger.cpp::2766.

When deleting the attachment, I first hit nsDelAttachListener::OnStopRunningUrl with a non-null mOriginalMessage and a "imap-message:" url, thus deleting the mOriginalMessage in nsMessenger.cpp::2852.
Trying to grab the original message's flags then crashes...

Comment 19

[David :Bienvenu]

is the memory cache turned off, or is the message too large to fit in the memory cache? Is the folder configured for offline use?

Comment 20

[Andrew Schultz]

> is the memory cache turned off, or is the message too large to fit in the
> memory cache? Is the folder configured for offline use?

No, no and no.  :(
I was hitting this with a ~150K word document (much smaller than the ~12MB memory cache gecko decides to use).

Comment 21

[Karsten Düsterloh]

> No, no and no.  :(

Same here, with Henrik's 37 KB message.

Comment 22

[David :Bienvenu]

Attachment: possible fix

this might fix the crash by caching away the message flags. But I don't know what happens downstream.

I had a more complicated fix that attempted to be agnostic about whether OnStopRequest or OnStopRunningUrl got called, but then I found I was not getting the resulting message selected, so I backed it out. But then I found out that was still true after backing it out, so I need to figure that out.

Comment 23

[David :Bienvenu]

has anyone been able to try this patch and see if it works for them?

Comment 24

[Andrew Schultz]

Comment on attachment 247912 [details] [diff] [review]
possible fix

yes, this fixes the crash

Comment 25

[David :Bienvenu]

Comment on attachment 247912 [details] [diff] [review]
possible fix

great, thx

Comment 26

[David :Bienvenu]

fixed on trunk and branch

Comment 27

[Andrew Schultz]

Comment on attachment 247912 [details] [diff] [review]
possible fix

>-  PRUint32 origMsgFlags;
>-  mOriginalMessage->GetFlags(&origMsgFlags);

Looks like this part didn't make it into the trunk.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/mailnews/base/src/nsMessenger.cpp&rev=1.347&mark=2765-2766#2738

Comment 28

[Andrew Schultz]

(not fixed on trunk)

Comment 29

[Karsten Düsterloh]

Comment on attachment 247912 [details] [diff] [review]
possible fix

JFTR: this patch, applied correctly to trunk, fixes the problem for me on Mac, too.

Comment 30

[David :Bienvenu]

thx for catching that - I had a merge conflict and messed up the hand-merge. Rest of fix checked into the trunk.

Comment 31

[Carsten Book [:Tomcat]]

Verified fixed for 1.8.1.1 on Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.1pre) Gecko/20061206 Thunderbird/2.0b1 ID:2006120615