Closed Bug 76200 Opened 23 years ago Closed 23 years ago

Mail crashes after opening HTML message with corrupted img field (very long ALT and no SRC)

Categories

(MailNews Core :: Backend, defect, P2)

Product:
MailNews Core
Component:
Backend
Platform:
x86
Windows ME
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: piskozub, Assigned: sspitzer)

References

Details

(Keywords: regression, Whiteboard: [nsbeta1+])

Attachments

(4 files)

The text of the message crashing Mozilla
858 bytes, text/html
Details
additional null checks for mImageRequest
3.12 KB, patch
Details | Diff | Splinter Review
fix to allow mScheme to be null
584 bytes, patch
Details | Diff | Splinter Review
fixing the caller, please review
1.02 KB, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.8.1+) Gecko/20010416
BuildID:    2001041604

Today Win32 installer build crashes on a messagge with all the text as a very
long IMG ALT field with no actual SRC in the field. I'll attach the culprit
HTML. This is a recent regression, I read and deleted this piece of SPAM with
20010411 morning build with no problem


Reproducible: Always
Steps to Reproduce:
1. Send this attached crap to yourself
2. Try to read the message
3. Crash

Actual Results:  Crash (after marking the message as read)


Expected Results:  Message opens showing anythng (the message is actually empty
except for the long IMG ALT field.

I mart this critical as this may lead to a very simple Denial of Service attack
Keywords: regression
More comment: Today build 20010416 crashes with an exception in necko.dll. The
above mentioned 20010411 crashed today on the message with gklayout.dll error
(however I am sure I read this message earlier with that build on another host).
Mozilla 0.8.1 does not crash showing an empty message (pretty reasonable) while
Netscape 4.77 shows the broken image icon with all the ALT text as one long line
(correct but not necessary reasonable). 

This means that:
- this is the new MailNews branch error
- something in the last four days made it even worse (crash every time, instead
of intermittant)
-> Composition

Oh, and BTW, I don't think this is related to the MailNews branch since that
didn't change Composition/Viewing of messages as far as I know.
Component: Mail Window Front End → Composition
You may be right but this HTML shows OK in a browser window. Therefore I assumed
(maybe wrong) that it has something to do with MailNews and as Mozilla 0.8.1
does not have it, the new branch seemed the best usual suspect. 
Since this is composer/HTML-renderer, maybe Editor has something to do with it?

CC beppe and brade
accepting.

it's a mail backend problem.

excellent bug report, Jacek
Status: UNCONFIRMED → ASSIGNED
Component: Composition → Mail Back End
Ever confirmed: true
here's the stack

the crasher is because mScheme is null.

nsStdURL::SchemeIs(nsStdURL * const 0x08acf900, const char * 0x025e29c8, int * 
0x0012ed4c) line 312 + 12 bytes
nsMsgMailNewsUrl::SchemeIs(nsMsgMailNewsUrl * const 0x08acf984, const char * 
0x025e29c8, int * 0x0012ed4c) line 486
GetCacheSession(nsIURI * 0x08acf984, nsICacheSession * * 0x0012ed9c) line 82
imgCache::Get(nsIURI * 0x08acf984, imgRequest * * 0x0012ef3c, 
nsICacheEntryDescriptor * * 0x0012eed4) line 183 + 33 bytes
imgLoader::LoadImage(imgLoader * const 0x025ae920, nsIURI * 0x08acf984, 
nsILoadGroup * 0x06bb5db0, imgIDecoderObserver * 0x08aceca0, nsISupports * 
0x066bbb70, imgIRequest * * 0x072e4fb4) line 78 + 40 bytes
nsImageFrame::Init(nsImageFrame * const 0x072e4f20, nsIPresContext * 0x066bbb70, 
nsIContent * 0x08a41500, nsIFrame * 0x072e4e48, nsIStyleContext * 0x08acd6f0, 
nsIFrame * 0x00000000) line 291 + 111 bytes
nsCSSFrameConstructor::InitAndRestoreFrame(nsIPresContext * 0x066bbb70, 
nsFrameConstructorState & {...}, nsIContent * 0x08a41500, nsIFrame * 0x072e4e48, 
nsIStyleContext * 0x08acd6f0, nsIFrame * 0x00000000, nsIFrame * 0x072e4f20) line 
6663 + 32 bytes
nsCSSFrameConstructor::ConstructFrameByTag(nsIPresShell * 0x066ae490, 
nsIPresContext * 0x066bbb70, nsFrameConstructorState & {...}, nsIContent * 
0x08a41500, nsIFrame * 0x072e4e48, nsIAtom * 0x0173df40 {"img"}, int 3, 
nsIStyleContext * 0x08acd6f0, nsFrameItems & {...}) line 4926
nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x066ae490, 
nsIPresContext * 0x066bbb70, nsFrameConstructorState & {...}, nsIContent * 
0x08a41500, nsIFrame * 0x072e4e48, nsIAtom * 0x0173df40 {"img"}, int 3, 
nsIStyleContext * 0x08acd6f0, nsFrameItems & {...}, int 0) line 7181 + 52 bytes
nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x066ae490, nsIPresContext 
* 0x066bbb70, nsFrameConstructorState & {...}, nsIContent * 0x08a41500, nsIFrame 
* 0x072e4e48, nsFrameItems & {...}) line 7091 + 56 bytes
nsCSSFrameConstructor::ContentAppended(nsCSSFrameConstructor * const 0x066a8460, 
nsIPresContext * 0x066bbb70, nsIContent * 0x06bcac00, int 0) line 8083
StyleSetImpl::ContentAppended(StyleSetImpl * const 0x066a8520, nsIPresContext * 
0x066bbb70, nsIContent * 0x06bcac00, int 0) line 1241
PresShell::ContentAppended(PresShell * const 0x066ae498, nsIDocument * 
0x089ae6d0, nsIContent * 0x06bcac00, int 0) line 4534 + 46 bytes
nsDocument::ContentAppended(nsDocument * const 0x089ae6d0, nsIContent * 
0x06bcac00, int 0) line 1537
nsHTMLDocument::ContentAppended(nsHTMLDocument * const 0x089ae6d0, nsIContent * 
0x06bcac00, int 0) line 1281 + 17 bytes
HTMLContentSink::NotifyAppend(nsIContent * 0x06bcac00, int 0) line 4574
SinkContext::FlushTags(int 1) line 2046
HTMLContentSink::CloseBody(HTMLContentSink * const 0x066eceb0, const 
nsIParserNode & {...}) line 2902
CNavDTD::CloseBody(const nsIParserNode * 0x071fc4b8) line 3134 + 31 bytes
CNavDTD::CloseContainer(const nsCParserNode * 0x071fc4b8, nsHTMLTag 
eHTMLTag_body, int 0) line 3532 + 12 bytes
CNavDTD::CloseContainersTo(int 1, nsHTMLTag eHTMLTag_body, int 0) line 3593 + 20 
bytes
CNavDTD::CloseContainersTo(nsHTMLTag eHTMLTag_body, int 0) line 3750 + 20 bytes
CNavDTD::DidBuildModel(CNavDTD * const 0x06b8d9f0, unsigned int 0, int 1, 
nsIParser * 0x089af3f0, nsIContentSink * 0x066eceb0) line 579
nsParser::DidBuildModel(unsigned int 0) line 1419 + 60 bytes
nsParser::ResumeParse(int 1, int 1) line 1958
nsParser::OnStopRequest(nsParser * const 0x089af3f8, nsIRequest * 0x089a1094, 
nsISupports * 0x0557eea0, unsigned int 0) line 2399 + 19 bytes
nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x089ad3f0, 
nsIRequest * 0x089a1094, nsISupports * 0x0557eea0, unsigned int 0) line 277
nsStreamConverter::OnStopRequest(nsStreamConverter * const 0x089ad340, 
nsIRequest * 0x089a1094, nsISupports * 0x0557eea0, unsigned int 0) line 1013
nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x089a2cb0, 
nsIRequest * 0x089a1094, nsISupports * 0x0557eea0, unsigned int 0) line 277
nsMsgProtocol::OnStopRequest(nsMsgProtocol * const 0x089a1090, nsIRequest * 
0x089a2884, nsISupports * 0x0557eea0, unsigned int 0) line 271 + 88 bytes
nsMailboxProtocol::OnStopRequest(nsMailboxProtocol * const 0x089a1090, 
nsIRequest * 0x089a2884, nsISupports * 0x0557eea0, unsigned int 0) line 204
nsOnStopRequestEvent::HandleEvent() line 159
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x089a20c4) line 64
PL_HandleEvent(PLEvent * 0x089a20c4) line 588 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00a0a990) line 518 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0047069e, unsigned int 49422, unsigned int 0, 
long 10529168) line 1069 + 9 bytes
USER32! 77e71820
Seth, I can fix it if it's just a matter of bullet-proofing..?
Keywords: nsbeta1
Priority: -- → P2
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.9
the lack of the src attribute (I bet the same thing would happen if we had 
src="") on the image gets eventually gets us to the point where 
nsScriptSecurityManager::GetCodebasePrincipal() calls NS_NewURI() with 
"mailbox://"

line 821, nsScriptSecurityManager.cpp:

rv = NS_NewURI(getter_AddRefs(newURI), originUrl, nsnull)

I think this might be a parser bug.

we could fix necko or mailnews to not crash in the mailbox:// case, but I think 
something bigger is broken.

mstoltz / harishd / mscott, any comments?

harishd, see #66673

I think it is related.
I take that back.  I was looking at the wrong thing.  "mailbox://" is ok, the 
problem comes from nsImageFrame::Init() calling NS_NewURI() with "".

it may still be parser related, I don't know enough about this.

here's the stack that includes that call to NS_NewURI()

nsMsgMailNewsUrl::nsMsgMailNewsUrl() line 46
nsMailboxUrl::nsMailboxUrl() line 129 + 27 bytes
nsMailboxUrlConstructor(nsISupports * 0x00000000, const nsID & {...}, void * * 
0x0012ee9c) line 49 + 87 bytes
nsGenericFactory::CreateInstance(nsGenericFactory * const 0x066b20f0, 
nsISupports * 0x00000000, const nsID & {...}, void * * 0x0012ee9c) line 56
nsComponentManagerImpl::CreateInstance(nsComponentManagerImpl * const 
0x009552f0, const nsID & {...}, nsISupports * 0x00000000, const nsID & {...}, 
void * * 0x0012ee9c) line 1199 + 24 bytes
nsComponentManager::CreateInstance(const nsID & {...}, nsISupports * 0x00000000, 
const nsID & {...}, void * * 0x0012ee9c) line 82
nsMailboxService::NewURI(nsMailboxService * const 0x066b3e6c, const char * 
0x04e5a030, nsIURI * 0x066c8bc4, nsIURI * * 0x0012f064) line 399 + 43 bytes
nsIOService::NewURI(const char * 0x04e5a030, nsIURI * 0x066c8bc4, nsIURI * * 
0x0012f064, nsIProtocolHandler * * 0x00000000) line 288 + 35 bytes
nsIOService::NewURI(nsIOService * const 0x0181bb80, const char * 0x04e5a030, 
nsIURI * 0x066c8bc4, nsIURI * * 0x0012f064) line 296
NS_NewURI(nsIURI * * 0x0012f064, const char * 0x04e5a030, nsIURI * 0x066c8bc4, 
nsIIOService * 0x0181bb80) line 77 + 24 bytes
NS_NewURI(nsIURI * * 0x0012f064, const nsAString & {...}, nsIURI * 0x066c8bc4, 
nsIIOService * 0x00000000) line 89 + 21 bytes
nsImageFrame::Init(nsImageFrame * const 0x0128bf48, nsIPresContext * 0x064e41f0, 
nsIContent * 0x04e5a060, nsIFrame * 0x013002d8, nsIStyleContext * 0x04e5a760, 
nsIFrame * 0x00000000) line 290 + 56 bytes
nsCSSFrameConstructor::InitAndRestoreFrame(nsIPresContext * 0x064e41f0, 
nsFrameConstructorState & {...}, nsIContent * 0x04e5a060, nsIFrame * 0x013002d8, 
nsIStyleContext * 0x04e5a760, nsIFrame * 0x00000000, nsIFrame * 0x0128bf48) line 
6663 + 32 bytes
nsCSSFrameConstructor::ConstructFrameByTag(nsIPresShell * 0x065120f0, 
nsIPresContext * 0x064e41f0, nsFrameConstructorState & {...}, nsIContent * 
0x04e5a060, nsIFrame * 0x013002d8, nsIAtom * 0x0184c140 {"img"}, int 3, 
nsIStyleContext * 0x04e5a760, nsFrameItems & {...}) line 4926
nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x065120f0, 
nsIPresContext * 0x064e41f0, nsFrameConstructorState & {...}, nsIContent * 
0x04e5a060, nsIFrame * 0x013002d8, nsIAtom * 0x0184c140 {"img"}, int 3, 
nsIStyleContext * 0x04e5a760, nsFrameItems & {...}, int 0) line 7181 + 52 bytes
nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x065120f0, nsIPresContext 
* 0x064e41f0, nsFrameConstructorState & {...}, nsIContent * 0x04e5a060, nsIFrame 
* 0x013002d8, nsFrameItems & {...}) line 7091 + 56 bytes
nsCSSFrameConstructor::ContentAppended(nsCSSFrameConstructor * const 0x06512480, 
nsIPresContext * 0x064e41f0, nsIContent * 0x06519c50, int 1) line 8083
StyleSetImpl::ContentAppended(StyleSetImpl * const 0x065133c0, nsIPresContext * 
0x064e41f0, nsIContent * 0x06519c50, int 1) line 1241
PresShell::ContentAppended(PresShell * const 0x065120f8, nsIDocument * 
0x066d2ce0, nsIContent * 0x06519c50, int 1) line 4534 + 46 bytes
nsDocument::ContentAppended(nsDocument * const 0x066d2ce0, nsIContent * 
0x06519c50, int 1) line 1537
nsHTMLDocument::ContentAppended(nsHTMLDocument * const 0x066d2ce0, nsIContent * 
0x06519c50, int 1) line 1281 + 17 bytes
HTMLContentSink::NotifyAppend(nsIContent * 0x06519c50, int 1) line 4574
SinkContext::FlushTags(int 1) line 2046
HTMLContentSink::CloseBody(HTMLContentSink * const 0x066d3150, const 
nsIParserNode & {...}) line 2902
CNavDTD::CloseBody(const nsIParserNode * 0x0122a0f0) line 3134 + 31 bytes
CNavDTD::CloseContainer(const nsCParserNode * 0x0122a0f0, nsHTMLTag 
eHTMLTag_body, int 0) line 3532 + 12 bytes
CNavDTD::CloseContainersTo(int 1, nsHTMLTag eHTMLTag_body, int 0) line 3593 + 20 
bytes
CNavDTD::CloseContainersTo(nsHTMLTag eHTMLTag_body, int 0) line 3750 + 20 bytes
CNavDTD::DidBuildModel(CNavDTD * const 0x0651ee40, unsigned int 0, int 1, 
nsIParser * 0x066d39b0, nsIContentSink * 0x066d3150) line 579
nsParser::DidBuildModel(unsigned int 0) line 1419 + 60 bytes
nsParser::ResumeParse(int 1, int 1) line 1958
nsParser::OnStopRequest(nsParser * const 0x066d39b8, nsIRequest * 0x066c8504, 
nsISupports * 0x066c8bc0, unsigned int 0) line 2399 + 19 bytes
nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x066d1af0, 
nsIRequest * 0x066c8504, nsISupports * 0x066c8bc0, unsigned int 0) line 277
nsStreamConverter::OnStopRequest(nsStreamConverter * const 0x066d1a40, 
nsIRequest * 0x066c8504, nsISupports * 0x066c8bc0, unsigned int 0) line 1013
nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x066c9fb0, 
nsIRequest * 0x066c8504, nsISupports * 0x066c8bc0, unsigned int 0) line 277
nsMsgProtocol::OnStopRequest(nsMsgProtocol * const 0x066c8500, nsIRequest * 
0x066c8d54, nsISupports * 0x066c8bc0, unsigned int 0) line 271 + 88 bytes
nsMailboxProtocol::OnStopRequest(nsMailboxProtocol * const 0x066c8500, 
nsIRequest * 0x066c8d54, nsISupports * 0x066c8bc0, unsigned int 0) line 204
nsOnStopRequestEvent::HandleEvent() line 159
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x066ccc04) line 64
PL_HandleEvent(PLEvent * 0x066ccc04) line 588 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00a0a990) line 518 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x10bb0116, unsigned int 49422, unsigned int 0, 
long 10529168) line 1069 + 9 bytes
USER32! 77e71820()
00a0a990()

I think we need some layout help on this one.  (cc'ing pavlov, since it is img 
related)

1) it looks like in the general case we don't display the internal "broken 
image" gif.  is there a bug on that?

2)  <img> without a src attribute or src="" should show the broken image gif.  

Where would that happen?  Can this check happen at nsImageFrame.cpp?  something 
like:

Index: html/base/src/nsImageFrame.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/html/base/src/nsImageFrame.cpp,v
retrieving revision 1.161
diff -u -w -r1.161 nsImageFrame.cpp
--- nsImageFrame.cpp    2001/04/11 08:12:10     1.161
+++ nsImageFrame.cpp    2001/04/16 22:50:16
@@ -287,6 +287,12 @@
   mCanSendLoadEvent = PR_TRUE;

   nsCOMPtr<nsIURI> srcURI;
+
+  // if src == "", there is nothing to load
+  if (src.Length() == 0) {
+         src = NS_LITERAL_STRING("chrome://communicator/skin/broken.gif").get()
;
+  }
+
   NS_NewURI(getter_AddRefs(srcURI), src, baseURL);
   il->LoadImage(srcURI, loadGroup, mListener, aPresContext, getter_AddRefs(mIma
geRequest));
   // if the image was found in the cache, it is possible that LoadImage will re
sult in a call to OnStartContainer()

if the source is broken, then it should fall through just like broken images and 
get replaced by the alt text.  we shouldn't special case url in the image frame, 
and we certainly shouldn't have a hardcoded chrome:// image in there.
i have to be able to call NewURI with "" since the baseurl should be merged in 
with it (and i suppose the base url could be an image url...)
bug 72447 is also due to SchemeIs crashing when mScheme is null.

I think we need to fix this in necko to say the scheme isn't whatever since the 
scheme is null (i suppose unless you pass in a null scheme.. heh)
pavlov:  what do we show if there isn't any alt text?  do we ever show that
internal "broken image" image anymore?

I'll go work on bullet proofing necko to handle this case and attach a patch.
we change the frame into a tiny textnode.  hixie says this is the correct 
behavior.
simply bullet proofing necko will lead to asserts and then a crash in layout.

here's the crash:

nsImageFrame::Paint(nsImageFrame * const 0x01219ce8, nsIPresContext * 
0x067fe430, nsIRenderingContext & {...}, const nsRect & {x=0 y=0 width=9000 
height=9000}, nsFramePaintLayer eFramePaintLayer_Underlay) line 985 + 53 bytes
nsContainerFrame::PaintChild(nsIPresContext * 0x067fe430, nsIRenderingContext & 
{...}, const nsRect & {x=-120 y=-120 width=19140 height=12705}, nsIFrame * 
0x01219ce8, nsFramePaintLayer eFramePaintLayer_Underlay) line 208
nsBlockFrame::PaintChildren(nsIPresContext * 0x067fe430, nsIRenderingContext & 
{...}, const nsRect & {x=-120 y=-120 width=19140 height=12705}, 
nsFramePaintLayer eFramePaintLayer_Underlay) line 6594
nsBlockFrame::Paint(nsBlockFrame * const 0x01219c10, nsIPresContext * 
0x067fe430, nsIRenderingContext & {...}, const nsRect & {x=-120 y=-120 
width=19140 height=12705}, nsFramePaintLayer eFramePaintLayer_Underlay) line 
6472
nsContainerFrame::PaintChild(nsIPresContext * 0x067fe430, nsIRenderingContext & 
{...}, const nsRect & {x=0 y=0 width=19140 height=12705}, nsIFrame * 0x01219c10, 
nsFramePaintLayer eFramePaintLayer_Underlay) line 208
nsBlockFrame::PaintChildren(nsIPresContext * 0x067fe430, nsIRenderingContext & 
{...}, const nsRect & {x=0 y=0 width=19140 height=12705}, nsFramePaintLayer 
eFramePaintLayer_Underlay) line 6594
nsBlockFrame::Paint(nsBlockFrame * const 0x01219b88, nsIPresContext * 
0x067fe430, nsIRenderingContext & {...}, const nsRect & {x=0 y=0 width=19140 
height=12705}, nsFramePaintLayer eFramePaintLayer_Underlay) line 6472
nsContainerFrame::PaintChild(nsIPresContext * 0x067fe430, nsIRenderingContext & 
{...}, const nsRect & {x=0 y=0 width=19140 height=12705}, nsIFrame * 0x01219b88, 
nsFramePaintLayer eFramePaintLayer_Underlay) line 208
nsContainerFrame::PaintChildren(nsIPresContext * 0x067fe430, nsIRenderingContext 
& {...}, const nsRect & {x=0 y=0 width=19140 height=12705}, nsFramePaintLayer 
eFramePaintLayer_Underlay) line 152
nsHTMLContainerFrame::Paint(nsHTMLContainerFrame * const 0x01218e24, 
nsIPresContext * 0x067fe430, nsIRenderingContext & {...}, const nsRect & {x=0 
y=0 width=19140 height=12705}, nsFramePaintLayer eFramePaintLayer_Underlay) line 
108
PresShell::Paint(PresShell * const 0x0676d1a4, nsIView * 0x05275270, 
nsIRenderingContext & {...}, const nsRect & {x=0 y=0 width=19140 height=12705}) 
line 4945 + 34 bytes
nsView::Paint(nsView * const 0x05275270, nsIRenderingContext & {...}, const 
nsRect & {x=0 y=0 width=19140 height=12705}, unsigned int 128, int & 268592757) 
line 275
nsViewManager::RenderDisplayListElement(DisplayListElement2 * 0x05e8f6c0, 
nsIRenderingContext & {...}) line 1394
nsViewManager::RenderViews(nsIView * 0x04d81ed0, nsIRenderingContext & {...}, 
const nsRect & {x=0 y=0 width=19140 height=12705}, int & 0) line 1319
nsViewManager::Refresh(nsIView * 0x04d81ed0, nsIRenderingContext * 0x05e8f950, 
const nsRect * 0x0012f694 {x=0 y=0 width=19140 height=12705}, unsigned int 1) 
line 885
nsViewManager::DispatchEvent(nsViewManager * const 0x0676e030, nsGUIEvent * 
0x0012f7d4, nsEventStatus * 0x0012f6d8) line 1913
HandleEvent(nsGUIEvent * 0x0012f7d4) line 68
nsWindow::DispatchEvent(nsWindow * const 0x04d83164, nsGUIEvent * 0x0012f7d4, 
nsEventStatus & nsEventStatus_eIgnore) line 701 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f7d4, nsEventStatus & 
nsEventStatus_eIgnore) line 727
nsWindow::OnPaint() line 3831 + 28 bytes
nsWindow::ProcessMessage(unsigned int 15, unsigned int 0, long 0, long * 
0x0012fbb4) line 2838 + 17 bytes
nsWindow::WindowProc(HWND__ * 0x000508da, unsigned int 15, unsigned int 0, long 
0) line 956 + 27 bytes
USER32! 77e719d0()
USER32! 77e71982()
NTDLL! 77f763a3()

pavlov, do you want this bad boy?
*** Bug 74035 has been marked as a duplicate of this bug. ***
why is it crashing there?  null pointer ?
yes, the mImageRequest is null.
maybe i'm blind, but everything in that function looks like it should check for 
mImageRequest being null.
with this patch, i don't see how it can crash from mImageRequest being null...  
although, i still don't see how it would crash in nsImageFrame::Paint without 
this patch.
Did this make it in?  If not will the patch make it in for 0.9?  cc'ing varada
so he can mark some bugs as dups that I think have a similar stack trace.
I've rebuilt and I'm not seeing this crasher anymore.  I do get an assert in 
IOService because the scheme is empty, but I can live with that:

NTDLL! 77f7629c()
nsDebug::Assertion(const char * 0x016c03d4, const char * 0x016c03cc, const char 
* 0x016c0394, int 219) line 286 + 13 bytes
nsDebug::WarnIfFalse(const char * 0x016c03d4, const char * 0x016c03cc, const 
char * 0x016c0394, int 219) line 392 + 21 bytes
nsIOService::GetProtocolHandler(nsIOService * const 0x01523f30, const char * 
0x00000000, nsIProtocolHandler * * 0x0012edd4) line 219 + 32 bytes
nsIOService::NewChannelFromURI(nsIOService * const 0x01523f30, nsIURI * 
0x04c1e984, nsIChannel * * 0x0012eee4) line 309 + 46 bytes
imgLoader::LoadImage(imgLoader * const 0x023988a0, nsIURI * 0x04c1e984, 
nsILoadGroup * 0x07145050, imgIDecoderObserver * 0x04c1fc80, nsISupports * 
0x075099d0, imgIRequest * * 0x0586ae0c) line 117 + 69 bytes
nsImageFrame::Init(nsImageFrame * const 0x0586ad78, nsIPresContext * 0x075099d0, 
nsIContent * 0x04c1eb90, nsIFrame * 0x0586aca0, nsIStyleContext * 0x04c1fdf0, 
nsIFrame * 0x00000000) line 303 + 111 bytes
nsCSSFrameConstructor::InitAndRestoreFrame(nsIPresContext * 0x075099d0, 
nsFrameConstructorState & {...}, nsIContent * 0x04c1eb90, nsIFrame * 0x0586aca0, 
nsIStyleContext * 0x04c1fdf0, nsIFrame * 0x00000000, nsIFrame * 0x0586ad78) line 
6663 + 32 bytes
nsCSSFrameConstructor::ConstructFrameByTag(nsIPresShell * 0x07484540, 
nsIPresContext * 0x075099d0, nsFrameConstructorState & {...}, nsIContent * 
0x04c1eb90, nsIFrame * 0x0586aca0, nsIAtom * 0x01552780 {"img"}, int 3, 
nsIStyleContext * 0x04c1fdf0, nsFrameItems & {...}) line 4926
nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x07484540, 
nsIPresContext * 0x075099d0, nsFrameConstructorState & {...}, nsIContent * 
0x04c1eb90, nsIFrame * 0x0586aca0, nsIAtom * 0x01552780 {"img"}, int 3, 
nsIStyleContext * 0x04c1fdf0, nsFrameItems & {...}, int 0) line 7181 + 52 bytes
nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x07484540, nsIPresContext 
* 0x075099d0, nsFrameConstructorState & {...}, nsIContent * 0x04c1eb90, nsIFrame 
* 0x0586aca0, nsFrameItems & {...}) line 7091 + 56 bytes
nsCSSFrameConstructor::ContentAppended(nsCSSFrameConstructor * const 0x074848d0, 
nsIPresContext * 0x075099d0, nsIContent * 0x074945a0, int 0) line 8083
StyleSetImpl::ContentAppended(StyleSetImpl * const 0x07484a00, nsIPresContext * 
0x075099d0, nsIContent * 0x074945a0, int 0) line 1241
PresShell::ContentAppended(PresShell * const 0x07484548, nsIDocument * 
0x07503290, nsIContent * 0x074945a0, int 0) line 4724 + 46 bytes
nsDocument::ContentAppended(nsDocument * const 0x07503290, nsIContent * 
0x074945a0, int 0) line 1537
nsHTMLDocument::ContentAppended(nsHTMLDocument * const 0x07503290, nsIContent * 
0x074945a0, int 0) line 1294 + 17 bytes
HTMLContentSink::NotifyAppend(nsIContent * 0x074945a0, int 0) line 4574
SinkContext::FlushTags(int 1) line 2046
HTMLContentSink::CloseBody(HTMLContentSink * const 0x07505610, const 
nsIParserNode & {...}) line 2902
CNavDTD::CloseBody(const nsIParserNode * 0x0580d4b8) line 3134 + 31 bytes
CNavDTD::CloseContainer(const nsCParserNode * 0x0580d4b8, nsHTMLTag 
eHTMLTag_body, int 0) line 3532 + 12 bytes
CNavDTD::CloseContainersTo(int 1, nsHTMLTag eHTMLTag_body, int 0) line 3593 + 20 
bytes
CNavDTD::CloseContainersTo(nsHTMLTag eHTMLTag_body, int 0) line 3750 + 20 bytes
CNavDTD::DidBuildModel(CNavDTD * const 0x0748e900, unsigned int 0, int 1, 
nsIParser * 0x07505ec0, nsIContentSink * 0x07505610) line 579
nsParser::DidBuildModel(unsigned int 0) line 1418 + 60 bytes
nsParser::ResumeParse(int 1, int 1) line 1901
nsParser::OnStopRequest(nsParser * const 0x07505ec8, nsIRequest * 0x074fae74, 
nsISupports * 0x065e2e50, unsigned int 0) line 2342 + 19 bytes
nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x074fa4c0, 
nsIRequest * 0x074fae74, nsISupports * 0x065e2e50, unsigned int 0) line 277
nsStreamConverter::OnStopRequest(nsStreamConverter * const 0x074fa410, 
nsIRequest * 0x074fae74, nsISupports * 0x065e2e50, unsigned int 0) line 1013
nsMsgProtocol::OnStopRequest(nsMsgProtocol * const 0x074fae70, nsIRequest * 
0x074fa624, nsISupports * 0x065e2e50, unsigned int 0) line 271 + 88 bytes
nsMailboxProtocol::OnStopRequest(nsMailboxProtocol * const 0x074fae70, 
nsIRequest * 0x074fa624, nsISupports * 0x065e2e50, unsigned int 0) line 204
nsOnStopRequestEvent::HandleEvent() line 159
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x074fb314) line 64
PL_HandleEvent(PLEvent * 0x074fb314) line 588 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00a0ad80) line 518 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x000d00da, unsigned int 49337, unsigned int 0, 
long 10530176) line 1069 + 9 bytes
USER32! 77e71820()
00a0ad80()

I'm checking if I've got patches from pavlov in my tree that need to be checked 
in.  if yes, I'll attach them here.  if no, I'll mark this fixed.
I have one fix in my tree that needs to be checked in.

it's a bullet proofing fix to nsStdURL.cpp to allow for the case where scheme is 
null.

here it comes, can I get a review?
adding darin and valeski to the cc list, for review of the netwerk change.
r/sr=darin on the mScheme check... but please make sure the indentation is
consistent ;-)
will do on the indentation.  once I get this landed, I'll log a bug on the
remaining assertion.
this has r=mscott.  waiting for drivers@mozilla.org
actually, mScheme is not allowed to be null. see 
http://bugzilla.mozilla.org/show_bug.cgi?id=73845. for now, the null checks 
above necko are the solution (until 73845 is fixed). please do not add this 
check to nsStdURL as it will hide the real problem. 
ok, I'll work on the caller.
here comes the patch.  we should remove this extra string copy when #73845 gets 
fixed.
Depends on: 73845
r=mscott
r=valeski on the ::SchemeIs() call in mail/news (4/18/01 16:19 patch).
a=blizzard for 0.9
fixed.

thanks blizzard.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 74840 has been marked as a duplicate of this bug. ***
*** Bug 76706 has been marked as a duplicate of this bug. ***
*** Bug 76667 has been marked as a duplicate of this bug. ***
note, messages with img tags without src attributes and with relative src
attributes caused this problem.

examples:
<img alt="foo">
<img src="foo.gif" alt="foo">
*** Bug 76387 has been marked as a duplicate of this bug. ***
Using build 2001-05-03 on win, mac and linux, I opened the attachment and did a 
send page to myself.  I opened the mail msg without crashing.  I did not see the 
problem back with build 4-16 so I'm not sure if this is all I need to do to test 
this.  I will check some of the duplicates too to see if those are also fixed. 
If the reporter could check this to that would be great.  
Yes, this bug is a history for me, too. Marking VERIFIED.
Status: RESOLVED → VERIFIED
Thanks!
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: