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)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.3final
People
(Reporter: stephend, Assigned: sspitzer)
References
()
Details
(Keywords: crash, Whiteboard: [adt2 RTM])
Crash Data
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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)
Reporter | ||
Comment 1•22 years ago
|
||
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).
Reporter | ||
Comment 2•22 years ago
|
||
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
Reporter | ||
Comment 4•22 years ago
|
||
Yet another testcase: http://goinside.com/98/4/art.html.
This appears to just crash rendering any ART images ;-(
Reporter | ||
Comment 5•22 years ago
|
||
Sorry, wrong bug (sigh). The comment was for bugscape 18335.
Comment 6•22 years ago
|
||
rods: can you take a look at this one? thanks!
Updated•22 years ago
|
Priority: -- → P2
Target Milestone: --- → mozilla1.1beta
Comment 7•22 years ago
|
||
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•22 years ago
|
||
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
Comment 10•22 years ago
|
||
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
Comment 12•22 years ago
|
||
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.
Reporter | ||
Comment 13•22 years ago
|
||
This crash is also occurring in the unsupported MacMozilla-MacO.dmg builds.
Comment 14•22 years ago
|
||
> 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•22 years ago
|
||
Stephen, do you still see this problem on the latest build?
Reporter | ||
Comment 16•22 years ago
|
||
Can't reproduce the crash/hang anymore, but it doesn't actually print the image
in the news message.
Assignee | ||
Updated•22 years ago
|
Target Milestone: mozilla1.1beta → ---
Assignee | ||
Comment 17•22 years ago
|
||
I recently added some bulletproofing for null m_request to the news code.
let me go find the bug # for that...
Status: NEW → ASSIGNED
Assignee | ||
Comment 18•22 years ago
|
||
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
Assignee | ||
Comment 19•22 years ago
|
||
*** Bug 146780 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 20•22 years ago
|
||
*** Bug 198134 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 21•22 years ago
|
||
*** Bug 92659 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 22•22 years ago
|
||
Assignee | ||
Comment 23•22 years ago
|
||
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
Comment 24•22 years ago
|
||
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
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
Updated•13 years ago
|
Crash Signature: [@ nsDocLoaderImpl::doStopDocumentLoad]
You need to log in
before you can comment on or make changes to this bug.
Description
•