7993 - Browser crashes when opening joecartoon.com

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[cpeterso]

I'm running Mozilla M6 on NT4 SP3.

Comment 1

[AriB]

me too M6 (talkback release)

APPRUNNER caused an invalid page fault in
module KERNEL32.DLL at 015f:bff76847.
Registers:
EAX=0069045c CS=015f EIP=bff76847 EFLGS=00010246
EBX=0069045c SS=0167 ESP=00690000 EBP=00690018
ECX=0069009c DS=0167 ESI=81702b70 FS=3a87
EDX=bff76859 ES=0167 EDI=006900c4 GS=0000
Bytes at CS:EIP:
ff 75 08 ff 55 18 83 c4 10 64 8f 05 00 00 00 00
Stack dump:
0069045c 006900e0 0069009c 0069045c bff76859 0069045c 006900ac bff87fc0 006900c4
0069045c 006900e0 0069009c bffbfe14 81702bb4 8170dfb0 00000000

Comment 2

[AriB]

btw with Win98

Comment 3

[don]

Bill,

This fails (but does not crash) on Win 98 for me with a "JavaScript error: Call
to nsXPCScriptable failed".  On Linux it crashes without any message.  Any
clues?  To whom can we assign this?

Comment 4

[Chris Petersen]

This problem still occurs with Apprunner June 28th Build (1999062809)

Comment 5

[Bill Law]

The problem seems to reside at a lower-level component.  Here's a stack trace at
the point it crashes (on my NT 4.0 SP3 system).  It seems to be caused by some
funky HTML content-arrival timing.  I'm resetting the component to the "layout"
component (I hope that's the right one).  Please note that the problem can be
recreated with viewer.exe, also.

NTDLL! 77f76148()
nsDebug::Assertion(const char * 0x0176f188, const char * 0x0176f168, const char
* 0x0176f134, int 0x000001b0) line 150 + 13 bytes
nsScrollFrame::Reflow(nsScrollFrame * const 0x05a844a4, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int &
0x00000001) line 432 + 38 bytes
nsContainerFrame::ReflowChild(nsIFrame * 0x05a844a0, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int &
0x00000001) line 392 + 28 bytes
ViewportFrame::Reflow(ViewportFrame * const 0x05a86084, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int &
0x00000001) line 438
nsHTMLReflowCommand::Dispatch(nsHTMLReflowCommand * const 0x05a93b70,
nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsSize & {...},
nsIRenderingContext & {...}) line 169
PresShell::ProcessReflowCommands(PresShell * const 0x05a7ee00) line 1241
PresShell::ExitReflowLock(PresShell * const 0x05a7ee00) line 660
PresShell::ContentAppended(PresShell * const 0x05a7ee08, nsIDocument *
0x05a6a4c0, nsIContent * 0x05a8709c, int 0x00000001) line 1655
nsDocument::ContentAppended(nsDocument * const 0x05a6a4c0, nsIContent *
0x05a8709c, int 0x00000001) line 1554
nsHTMLDocument::ContentAppended(nsHTMLDocument * const 0x05a6a4c0, nsIContent *
0x05a8709c, int 0x00000001) line 701
HTMLContentSink::WillInterrupt(HTMLContentSink * const 0x05a69bd0) line 1576
CNavDTD::WillInterruptParse(CNavDTD * const 0x05a7ff20) line 2983 + 27 bytes
nsParser::ResumeParse(nsIDTD * 0x00000000) line 886
nsParser::OnDataAvailable(nsParser * const 0x05a69d34, nsIURI * 0x0573b2c0,
nsIInputStream * 0x05a68340, unsigned int 0x00000a0d) line 1160 + 17 bytes
nsDocumentBindInfo::OnDataAvailable(nsDocumentBindInfo * const 0x05738b10,
nsIURI * 0x0573b2c0, nsIInputStream * 0x05a68340, unsigned int 0x00000a0d) line
1984 + 24 bytes
OnDataAvailableProxyEvent::HandleEvent(OnDataAvailableProxyEvent * const
0x05a84150) line 634
StreamListenerProxyEvent::HandlePLEvent(PLEvent * 0x05a84154) line 473 + 12
bytes
PL_HandleEvent(PLEvent * 0x05a84154) line 493 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00c64f90) line 454 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x014808fa, unsigned int 0x0000c0e4, unsigned int
0x00000000, long 0x00c64f90) line 912 + 9 bytes
USER32! 77e713ed()
00c64f90()

Comment 6

[Chris Petersen]

With the July 1 build (Mac, Win 98, Linux), the crash still occurs.

Comment 7

[rickg]

Troy -- this is terminating on the assertion that the reflowstate has a "bad
status", line 504. Please take a look. Abbreviated stack frame below:

nsDebug::Assertion(const char * 0x015151fc, const char * 0x015151dc, const char
* 0x015151a8, int 503) line 167 + 13 bytes
nsScrollFrame::Reflow(nsScrollFrame * const 0x007c1c44, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 1)
line 503 + 38 bytes
nsContainerFrame::ReflowChild(nsIFrame * 0x007c1c40, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 1)
line 392 + 28 bytes
ViewportFrame::Reflow(ViewportFrame * const 0x007c1f84, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 1)
line 440
nsHTMLReflowCommand::Dispatch(nsHTMLReflowCommand * const 0x0165c8a0,
nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsSize & {...},
nsIRenderingContext & {...}) line 169
PresShell::ProcessReflowCommands(PresShell * const 0x007c5a50) line 1285
PresShell::ExitReflowLock(PresShell * const 0x007c5a50) line 664
PresShell::ContentAppended(PresShell * const 0x007c5a58, nsIDocument *
0x01652e90, nsIContent * 0x007c042c, int 1) line 1699
nsDocument::ContentAppended(nsDocument * const 0x01652e90, nsIContent *
0x007c042c, int 1) line 1551
nsHTMLDocument::ContentAppended(nsHTMLDocument * const 0x01652e90, nsIContent *
0x007c042c, int 1) line 701

Comment 8

[troy]

I reduced this down as far as I could. The key things are the CENTER tag and the
OBJECT tag.

What happens is we process an incremental reflow and it goes to the HTML
element's frame and then to the BODY's frame and it returns that it isn't
complete. That's bad and we hit an assert

Here's the reduced HTML:

<html>
<body>
<center>
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://active.macromedia.com/flash2/cabs/swflash.cab#version=3,0,0,0"
id="newface" width="75%" height="75%">
</object>
<br>
</center>
</body>
</html>

Comment 9

[kipp]

The actual problem was in the object tag handling code (nsObjectFrame). I fixed
it to handle % height (or width) in unconstrained situations better.

Comment 10

[Chris Petersen]

The crash in nolonger occuring when loading the page. Tested with the July 09
build.