Closed Bug 159995 Opened 22 years ago Closed 22 years ago

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

Categories

(MailNews Core :: Printing, defect, P2)

x86
Windows 2000
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.3final

People

(Reporter: stephend, Assigned: sspitzer)

References

()

Details

(Keywords: crash, Whiteboard: [adt2 RTM])

Crash Data

Attachments

(2 files)

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/3D458694.1010706@netscape.com 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)
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).
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.
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
Yet another testcase: http://goinside.com/98/4/art.html. This appears to just crash rendering any ART images ;-(
Sorry, wrong bug (sigh). The comment was for bugscape 18335.
rods: can you take a look at this one? thanks!
Blocks: 143047
Keywords: nsbeta1+
Whiteboard: [adt2 RTM] [ETA Needed]
Priority: -- → P2
Target Milestone: --- → mozilla1.1beta
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!
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?
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
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
Assignee: rods → sspitzer
over to mailnews
Product: Browser → MailNews
Attached patch patch that stops crash (deleted) — Splinter Review
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.
This crash is also occurring in the unsupported MacMozilla-MacO.dmg builds.
> 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().
Stephen, do you still see this problem on the latest build?
Can't reproduce the crash/hang anymore, but it doesn't actually print the image in the news message.
Target Milestone: mozilla1.1beta → ---
I recently added some bulletproofing for null m_request to the news code. let me go find the bug # for that...
Status: NEW → ASSIGNED
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.
Whiteboard: [adt2 RTM] [ETA Needed] → [adt2 RTM]
Target Milestone: --- → mozilla1.4beta
*** Bug 146780 has been marked as a duplicate of this bug. ***
*** Bug 198134 has been marked as a duplicate of this bug. ***
*** Bug 92659 has been marked as a duplicate of this bug. ***
Attached patch fix (deleted) — Splinter Review
fix checked in, it has r/sr=bienvenu, a=sspitzer back ported to 1.3.1, too.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
QA Contact: sujay → nbaca
Resolution: --- → FIXED
Target Milestone: mozilla1.4beta → mozilla1.3final
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.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
Crash Signature: [@ nsDocLoaderImpl::doStopDocumentLoad]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: