303336 - [FIXr]stack overflow crash when I try to open an attachment with forwarded message

Status: VERIFIED FIXED

(MailNews Core :: Attachments, defect, P1)

Description

[DooShan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050725 MultiZilla/1.8.0.1h SeaMonkey/1.0a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050726 MultiZilla/1.8.0.1h SeaMonkey/1.0a

When I try to open an attached message that was forwarded to me as an
attachment, the SeaMonkey application stops responding and eventually crashes.
If there were more attached messages the application crashes quicker. The
problem started to appear in SeaMonkey 2005-07-26 and appears till current
nightly (2005-08-03-06-trunk). The problem is not in SeaMonkey 2005-07-25 and
prior versions. I am on Windows 2000 and I am getting my email through IMAP on
Microsoft Exchange.

Reproducible: Always

Steps to Reproduce:
1. Forward a message as an attachment to myself or let somebody send it to you.
2. Try to open that attached message.
3. SeaMonkey crashes.

Actual Results:  
Crash

Expected Results:  
Open the attached message.

No talkback appeared, no errors, nothing, the SeaMonkey application just
disappeared.

Comment 1

[Mike Cowperthwaite]

xref bug 303601

Comment 2

[Frank Wein [:mcsmurf]]

Stacktrace:
nsXPCWrappedJS::CallMethod(nsXPCWrappedJS * const 0x08992360, unsigned short 5,
const nsXPTMethodInfo * 0x02aad230, nsXPTCMiniVariant * 0x00033920) line 462
PrepareAndDispatch(nsXPTCStubBase * 0x00000000, unsigned int 5, unsigned int *
0x000339d8, unsigned int * 0x000339c8) line 117 + 18 bytes
SharedStub() line 147
nsDocumentOpenInfo::TryContentListener(nsDocumentOpenInfo * const 0x00008000,
nsIURIContentListener * 0x08992360, nsIChannel * 0x09382014) line 724
nsDocumentOpenInfo::DispatchContent(nsDocumentOpenInfo * const 0x00008000,
nsIRequest * 0x09382014, nsISupports * 0x058c2548) line 515 + 13 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x0bdd0108,
nsIRequest * 0x09382014, nsISupports * 0x058c2548) line 345 + 13 bytes
nsStreamConverter::OnStartRequest(nsStreamConverter * const 0x23f416a0,
nsIRequest * 0x09382014, nsISupports * 0x058c2548) line 961 + 10 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x0bdcb5c8,
nsIRequest * 0x09382014, nsISupports * 0x058c2548) line 356 + 12 bytes
nsStreamConverter::OnStartRequest(nsStreamConverter * const 0x23f3cb70,
nsIRequest * 0x09382014, nsISupports * 0x058c2548) line 961 + 10 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x0bdcaa78,
nsIRequest * 0x09382014, nsISupports * 0x058c2548) line 356 + 12 bytes
nsStreamConverter::OnStartRequest(nsStreamConverter * const 0x23f3c020,
nsIRequest * 0x09382014, nsISupports * 0x058c2548) line 961 + 10 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x0bdcfdc0,
nsIRequest * 0x09382014, nsISupports * 0x058c2548) line 356 + 12 bytes
nsStreamConverter::OnStartRequest(nsStreamConverter * const 0x23f3b4d0,
nsIRequest * 0x09382014, nsISupports * 0x058c2548) line 961 + 10 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x0bdcf270,
nsIRequest * 0x09382014, nsISupports * 0x058c2548) line 356 + 12 bytes
nsStreamConverter::OnStartRequest(nsStreamConverter * const 0x23f40948,
nsIRequest * 0x09382014, nsISupports * 0x058c2548) line 961 + 10 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x0bdc7890,
nsIRequest * 0x09382014, nsISupports * 0x058c2548) line 356 + 12 bytes
nsStreamConverter::OnStartRequest(nsStreamConverter * const 0x23f39e20,
nsIRequest * 0x09382014, nsISupports * 0x058c2548) line 961 + 10 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x0bdc6d40,
nsIRequest * 0x09382014, nsISupports * 0x058c2548) line 356 + 12 bytes
nsStreamConverter::OnStartRequest(nsStreamConverter * const 0x23f392d0,
nsIRequest * 0x09382014, nsISupports * 0x058c2548) line 961 + 10 bytes
[loop continues]
Maybe fallout from Bug 244964?

Comment 3

[Frank Wein [:mcsmurf]]

Crap, the stacktrace misses the first part, insert this at the beginning:
NTDLL! 77882a6b()
NTDLL! 778cc1d0()
MSVCRT! 78001532()
MSVCRT! 780014cf()
JS_vsmprintf(const char * 0x0114a5ec `string', char * 0x0003339c) line 1104 + 34
bytes
Sprint(Sprinter * 0x000333d4, const char * 0x0114a5ec `string') line 356 + 15 bytes
QuoteString(Sprinter * 0x000333d4, JSString * 0x08e2bfa0, unsigned short 34)
line 391 + 35 bytes
js_QuoteString(JSContext * 0x01cbf790, JSString * 0x08e2bfa0, unsigned short 34)
line 454 + 44 bytes
js_ValueToSource(JSContext * 0x01cbf748, long 149077924) line 2757 + 13 bytes
InitExceptionObject(JSContext * 0x01cbf748, JSObject * 0x08e2bfb0, JSString *
0x00000001, JSString * 0x23f3e1e8, unsigned int 1) line 447 + 7 bytes
js_ErrorToException(JSContext * 0x08e2bfb8, const char * 0x23f3e3b0,
JSErrorReport * 0x03824450) line 1024 + 14 bytes
ReportError(JSContext * 0x01cbf748, const char * 0x23f3e3b0, JSErrorReport *
0x00033510) line 687 + 13 bytes
js_ReportErrorNumberVA(JSContext * 0x00000000, unsigned int 603186096, const
JSErrorFormatString * (void *, const char *, const unsigned int)* 0x010d1eab
_js_GetErrorMessage, void * 0x00000000, const unsigned int 26, int 1, char *
0x00033574) line 983 + 13 bytes
JS_ReportErrorNumber(JSContext * 0x01cbf748, const JSErrorFormatString * (void
*, const char *, const unsigned int)* 0x010d1eab _js_GetErrorMessage, void *
0x00000000, const unsigned int 26) line 4191 + 25 bytes
js_Interpret(JSContext * 0x01cbf748, unsigned char * 0x01bfdb28, long *
0x00033778) line 1802 + 15 bytes
js_Invoke(JSContext * 0x00000001, unsigned int 2, unsigned int 2) line 1193 + 12
bytes
nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJSClass * const 0x02afb8d0,
nsXPCWrappedJS * 0x02992360, unsigned short 5, const nsXPTMethodInfo *
0x02aad230, nsXPTCMiniVariant * 0x00033920) line 1339 + 16 bytes

Comment 4

[timeless]

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

Comment 5

[Frank Wein [:mcsmurf]]

Bonsai link:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-07-25+04%3A00%3A00&maxdate=2005-07-26+06%3A00%3A00&cvsroot=%2Fcvsroot

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch -- use a valid content type

With things as they are, the imap mock channel never ends up with a nonempty
MIME type...

Comment 7

[David :Bienvenu]

Comment on attachment 192770 [details] [diff] [review]
Patch -- use a valid content type

Darin's on vacation - so I'm taking the liberty of switching the sr request to
mscott - hope that's ok!

Comment 8

[Frank Wein [:mcsmurf]]

Comment on attachment 192770 [details] [diff] [review]
Patch -- use a valid content type

regressed before branching

Comment 9

[Boris Zbarsky [:bzbarsky]]

Fixed on trunk and 1.8 branch.

Comment 10

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using build 2005-08-16-12 trunk SeaMonkey on Windows XP.

(Please replace fixed1.8 keyword with verified1.8 when branch verification happens.)