159995 - Crash in [@ nsDocLoaderImpl::doStopDocumentLoad] cancelling print of news message with attachment.

Status: VERIFIED FIXED

(MailNews Core :: Printing, defect, P2)

Description

[[e-mail] (gone - use [e-mail] instead)]

Build ID: Latest commercial 1.0 branch build, Windows 2000.

NOTE: This only affects messages with attachments.  Simple messages with nothing
in them are fine.

Summary: Crash in nsDocLoaderImpl::doStopDocumentLoad trying to cancel print of
a message.

Steps to Reproduce:

1.  Try to cancel the print of this message -
news://news.mozilla.org:119/[e-mail]

Expected Results:

Message print dialog disappears, nothing else happens.

Actual Results:  

We crash in:

0x03024bb0
nsDocLoaderImpl::doStopDocumentLoad
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 834]
nsDocLoaderImpl::DocLoaderIsEmpty
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 732]
nsDocLoaderImpl::OnStopRequest
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 663]
nsLoadGroup::RemoveRequest
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsLoadGroup.cpp, line 531]
imgRequestProxy::OnStopRequest
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgRequestProxy.cpp, line 392]
imgRequest::OnStopRequest
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgRequest.cpp, line 648]
ProxyListener::OnStopRequest
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgLoader.cpp, line 707]
nsMsgProtocol::OnStopRequest
[d:\builds\seamonkey\mozilla\mailnews\base\util\nsMsgProtocol.cpp, line 344]
nsNNTPProtocol::OnStopRequest
[d:\builds\seamonkey\mozilla\mailnews\news\src\nsNNTPProtocol.cpp, line 1245]
nsOnStopRequestEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp, line 213]
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 597]
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 530]
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line
1078]
nsAppShellService::Run
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 458]
main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1492]
main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1839]
WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1857]
WinMainCRTStartup()
KERNEL32.dll + 0x2847c (0x77ea847c)

Comment 1

[[e-mail] (gone - use [e-mail] instead)]

The message originates from news://news.mozilla.org/netscape.test.  Look for
subject [Fwd: word document], posted at 11:16 am today (7-29-2002).

Comment 2

[[e-mail] (gone - use [e-mail] instead)]

Just to clarify, I meant 'cancel the print dialog', not the printing progress
one - and this is while you are in Mail, not reading the posting via the browser.

Comment 3

[grylchan]

when I try this with commercial branch
  -20020725 on Nt 4.0
  -20020729 on Win2k

I see slightly different results (but still a crash).

1.select a news mesg w/attachment
2 [details] [diff] [review].open in stand alone window 
3.Click print button
4.Cancel print dialog 
5.NO crash
6.Close mesg
7.Select another news mesg w/attachment
8 [details].Click print button
9. result: nothing happens. NO print dialog
10.wait about 5 seconds, still nothing.
11.Do a File|Quit

result: as mozilla starts to shut down, then print dialog window
        appears. If I click cancel then crash will occur.

        
Talkback id: 8789790 . Same stack trace as in already posted.
0x00020027 
nsDocLoaderImpl::doStopDocumentLoad 
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 834] 
nsDocLoaderImpl::DocLoaderIsEmpty 
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 732] 


TB8789790W

Comment 4

[[e-mail] (gone - use [e-mail] instead)]

Yet another testcase:  http://goinside.com/98/4/art.html.

This appears to just crash rendering any ART images ;-(

Comment 5

[[e-mail] (gone - use [e-mail] instead)]

Sorry, wrong bug (sigh).  The comment was for bugscape 18335.

Comment 6

[Jaime Rodriguez, Jr.]

rods: can you take a look at this one? thanks!

Comment 7

[Jaime Rodriguez, Jr.]

dcone: Don, Chris thought you might be able to take a look at this crasher. Can
you take a quick look at it, and let us know what the chances are for getting a
quick and easy fix might be? thanks!

Comment 8

[rods (gone)]

I added a news item to n.p.m.ui with an html attachment. I cannot reproduce this
with the steps described in comment #3 with today's branch (I also can't
reproduce this with the trunk either). Is there another way to reproduce this?

Comment 9

[grylchan]

Rods,
Sorry didn't respond sooner. You can only see this
bug if you try to print a news mesg with a jpeg/gif
as an attachment. 

I was not able to reproduce this with a news mesg
that contains a html or doc or pdf attachment.

I was able to produce the crash: TB9012696H,TB9012857E
on 2002-08-05-12-1.0 on nt 4.0.

steps
1.select news mesg w/gif or jpeg attach
2.go to toolbar and hit print button
3.Nothing happens (no print dialog window).
4.Try again (if you don't hitting the print button
  couple of times, it may exit gracefully and not crash)
5.Hit print button one more time.
6.File|Quit

result: print window dialog appears and if you hit cancel button
        it will crash

Comment 10

[rods (gone)]

The problem is m_request is NULL in nsMsgProtocol::Cancel and it returns an
error code, but the msgPrintEngine never gets notified that an error has
occurred or more importantly that the document has stopped loading (with an error)

Later at shutdown it gets the notification that the document has stoped loading
and display the print dialog. If you press "Print" it go into some loop and then
later asks you to print again. If you hit cancel it ends up crashing, but
everything is really hosed at that point.

nsMsgProtocol::Cancel(nsMsgProtocol * const 0x04cea128, unsigned int 2152398850)
line 650
nsNNTPProtocol::Cancel(nsNNTPProtocol * const 0x04cea128, unsigned int
2152988678) line 1258
imgRequest::Cancel(unsigned int 2152988678) line 263
imgRequest::OnDataAvailable(imgRequest * const 0x04cee838, nsIRequest *
0x04cea128, nsISupports * 0x00000000, nsIInputStream * 0x04c8c790, unsigned int
0, unsigned int 2290) line 728
ProxyListener::OnDataAvailable(ProxyListener * const 0x04cee8d8, nsIRequest *
0x04cea128, nsISupports * 0x00000000, nsIInputStream * 0x04c8c790, unsigned int
0, unsigned int 2290) line 718
nsNntpCacheStreamListener::OnDataAvailable(nsNntpCacheStreamListener * const
0x04c5a878, nsIRequest * 0x04c8c788, nsISupports * 0x00000000, nsIInputStream *
0x04c8c790, unsigned int 0, unsigned int 2290) line 756 + 51 bytes
nsStorageTransport::nsReadRequest::OnDataAvailable(nsStorageTransport::nsReadRequest
* const 0x04c8c78c, nsIRequest * 0x04c8c788, nsISupports * 0x00000000,
nsIInputStream * 0x04c8c790, unsigned int 0, unsigned int 2290) line 625 + 46 bytes
XPTC_InvokeByIndex(nsISupports * 0x04c8c78c, unsigned int 5, unsigned int 5,
nsXPTCVariant * 0x04c15358) line 106
EventHandler(PLEvent * 0x04c15248) line 567 + 41 bytes
PL_HandleEvent(PLEvent * 0x04c15248) line 596 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x0140da08) line 526 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0010064e, unsigned int 49536, unsigned int 0,
long 21027336) line 1077 + 9 bytes

Comment 11

[rods (gone)]

over to mailnews

Comment 12

[rods (gone)]

Attachment: patch that stops crash

This patch will stop the crash, but it doesn't stop printing from getting
completely hosed.

It is "suppose" to be getting the attached image from the cache, I am not sure
why the m_request is being set to null.

Should this be a RTM1? Because if you print a News item with an attachment
printing gets completely hosed.

Comment 13

[[e-mail] (gone - use [e-mail] instead)]

This crash is also occurring in the unsupported MacMozilla-MacO.dmg builds.

Comment 14

[Cavin Song]

> I am not sure why the m_request is being set to null.
>
m_request is set to 0 in nsMsgProtocol::CloseSocket() and it's probably called 
by nsNNTPProtocol::OnStopRequest().

Comment 15

[Cavin Song]

Stephen, do you still see this problem on the latest build?

Comment 16

[[e-mail] (gone - use [e-mail] instead)]

Can't reproduce the crash/hang anymore, but it doesn't actually print the image
in the news message.

Comment 17

[(not reading, please use [e-mail] instead)]

I recently added some bulletproofing for null m_request to the news code.

let me go find the bug # for that...

Comment 18

[(not reading, please use [e-mail] instead)]

as far as the crasher not being there on a null m_request, that was probably
fixed by darin's async rewrite, not by me.

but, I found the problem and have a fix for the "on print or print preview,
attachments not showing up for news messages."

it's a simple fix.  here's the problem:

when we'd go to load the image, we'd cancel the request because we don't have
any image decoders for message/rfc822.

we shouldn't, because that's not an image type!

that cancel was causing the crash, here's the stack to the assert:

NTDLL! 77f9180c()
nsDebug::Assertion(const char * 0x020513f4, const char * 0x020513e8, const char
* 0x020513ac, int 711) line 270 + 13 bytes
nsMsgProtocol::Cancel(nsMsgProtocol * const 0x04644b68, unsigned int 2152398850)
line 711 + 41 bytes
nsNNTPProtocol::Cancel(nsNNTPProtocol * const 0x04644b68, unsigned int
2152988678) line 1286
imgRequest::Cancel(unsigned int 2152988678) line 265
imgRequest::OnDataAvailable(imgRequest * const 0x04db2ba0, nsIRequest *
0x04644b68, nsISupports * 0x00000000, nsIInputStream * 0x04dad904, unsigned int
0, unsigned int 4096) line 768
ProxyListener::OnDataAvailable(ProxyListener * const 0x04db2c40, nsIRequest *
0x04644b68, nsISupports * 0x00000000, nsIInputStream * 0x04dad904, unsigned int
0, unsigned int 4096) line 872
nsNntpCacheStreamListener::OnDataAvailable(nsNntpCacheStreamListener * const
0x04d948d0, nsIRequest * 0x04dadc20, nsISupports * 0x00000000, nsIInputStream *
0x04dad904, unsigned int 0, unsigned int 4096) line 757 + 51 bytes
nsInputStreamPump::OnStateTransfer() line 418 + 65 bytes
nsInputStreamPump::OnInputStreamReady(nsInputStreamPump * const 0x04dadc24,
nsIAsyncInputStream * 0x04dad904) line 321 + 11 bytes
nsInputStreamReadyEvent::EventHandler(PLEvent * 0x04d882d4) line 117
PL_HandleEvent(PLEvent * 0x04d882d4) line 659 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00f114c0) line 592 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x003b0c02, unsigned int 49506, unsigned int 0,
long 15799488) line 1395 + 9 bytes
USER32! 77e3a244()
USER32! 77e145e5()
USER32! 77e1a792()
nsAppShellService::Run(nsAppShellService * const 0x015cb408) line 479
main1(int 2, char * * 0x00271b40, nsISupports * 0x00ef3f98) line 1268 + 32 bytes
main(int 2, char * * 0x00271b40) line 1647 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77ea847c()

so now the question is why do we think the attachment is of content type
message/rf822?  Well, the news code is telling it that.

when we try to run an url like:

news://news.mozilla.org:119/b58dme%24aia2%40ripley.netscape.com?header=print&part=1.2&type=image/jpeg&filename=Pole.jpg

we are supposed to realize it's a nntp url of action type ActionFetchPart.

that happens in nsNntpUrl::DetermineNewsAction()

except I have code that does this:

if (PL_strcasestr(path.get(), "?part=") {

but duh, I need this:

if (PL_strcasestr(path.get(), "?part=") || PL_strcasestr(path.get(), "&part=")) {

the wrong action on the url messes up nsNNTPProtocol::SetupPartExtractorListener().

I'll back port to 1.3.1, too.

Comment 19

[(not reading, please use [e-mail] instead)]

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

Comment 20

[(not reading, please use [e-mail] instead)]

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

Comment 21

[(not reading, please use [e-mail] instead)]

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

Comment 22

[(not reading, please use [e-mail] instead)]

Attachment: fix

Comment 23

[(not reading, please use [e-mail] instead)]

fix checked in, it has r/sr=bienvenu, a=sspitzer

back ported to 1.3.1, too.

Comment 24

[Ninoschka Baca]

Trunk build 2003-04-25: WinXP
Verified Fixed, using an news message with an attached gif file and another
message with an attached jpg file. 

- Print Preview: ok.
- Canceled the print dialog multiple times, then printed successfully - ok.
- After an exit it also did not crash - ok.