Closed Bug 7993 Opened 25 years ago Closed 25 years ago

Browser crashes when opening joecartoon.com

Categories

(Core :: Layout, defect, P1)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: cpeterso, Assigned: buster)

References

()

Details

I'm running Mozilla M6 on NT4 SP3.
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
btw with Win98
Assignee: don → law
Component: Apprunner → other
Priority: P3 → P1
Target Milestone: M8
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?
QA Contact: leger → petersen
Status: NEW → ASSIGNED
This problem still occurs with Apprunner June 28th Build (1999062809)
Assignee: law → rickg
Status: ASSIGNED → NEW
Component: other → Layout
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()
With the July 1 build (Mac, Win 98, Linux), the crash still occurs.
Assignee: rickg → troy
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
Assignee: troy → kipp
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>
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
The actual problem was in the object tag handling code (nsObjectFrame). I fixed it to handle % height (or width) in unconstrained situations better.
Status: RESOLVED → VERIFIED
The crash in nolonger occuring when loading the page. Tested with the July 09 build.
You need to log in before you can comment on or make changes to this bug.