Closed Bug 17148 Opened 25 years ago Closed 25 years ago

[CRASH] Closing some tags in tbody causes crash.

Categories

(Core :: DOM: HTML Parser, defect, P3)

x86
Windows 98
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: hyp-x, Assigned: harishd)

References

()

Details

(Whiteboard: [TESTCASE])

Attachments

(1 file)

Version tested:
  1999102308 both mozilla and viewer on Win98

Description:
  The following html causes mozilla (and viewer) to crash:
---
<center>
<table>
  <tr><td>foo</td></tr>
</center>
</table>
---

MOZILLA caused an invalid page fault in
module GKHTML.DLL at 015f:601a3a93.
Registers:
EAX=000001a1 CS=015f EIP=601a3a93 EFLGS=00010202
EBX=00000000 SS=0167 ESP=0063f6f8 EBP=0063f718
ECX=0102d1e0 DS=0167 ESI=0102a150 FS=1a7f
EDX=0102950a ES=0167 EDI=00000000 GS=0000
Bytes at CS:EIP:
8b 08 ff 51 3c 8b 45 fc 50 8b 08 ff 51 08 8b ce
Stack dump:
000001a1 0102a0bc 00000000 00000001 0125b030 00000000 00000000 0102a0bc 0063f740
601a424f 00000000 00000000 0102ce10 00000003 0125b108 0125b088
Attached file Testcase for crash
Whiteboard: [TESTCASE]
Assignee: rickg → harishd
Harish: this looks like one for you. Here's the stack trace:

NTDLL! 77f76148()
nsDebug::Assertion(const char * 0x0138733c, const char * 0x0138732c, const char
* 0x013872f0, int 1592) line 280 + 13 bytes
SinkContext::FlushText(int * 0x00000000) line 1592 + 35 bytes
HTMLContentSink::EndContext(HTMLContentSink * const 0x022e5f20, int 2) line 1910
CNavDTD::HandleSavedTokensAbove(nsHTMLTag eHTMLTag_table) line 1577
CNavDTD::HandleEndToken(CToken * 0x0228ddc0) line 1485 + 18 bytes
CNavDTD::HandleToken(CNavDTD * const 0x022d4bc0, CToken * 0x0228ddc0, nsIParser
* 0x022e41a0) line 656 + 12 bytes
CNavDTD::BuildModel(CNavDTD * const 0x022d4bc0, nsIParser * 0x022e41a0,
nsITokenizer * 0x022d60b0, nsITokenObserver * 0x00000000, nsIContentSink *
0x022e5f20) line 458 + 20 bytes
nsParser::BuildModel() line 1038 + 34 bytes
nsParser::ResumeParse(nsIDTD * 0x00000000, int 0) line 949 + 11 bytes
nsParser::OnDataAvailable(nsParser * const 0x022e41a4, nsIChannel * 0x022e2a30,
nsISupports * 0x00000000, nsIInputStream * 0x022e3048, unsigned int 0, unsigned
int 98) line 1376 + 19 bytes
nsDocumentBindInfo::OnDataAvailable(nsDocumentBindInfo * const 0x022e2c20,
nsIChannel * 0x022e2a30, nsISupports * 0x00000000, nsIInputStream * 0x022e3048,
unsigned int 0, unsigned int 98) line 1200 + 32 bytes
nsChannelListener::OnDataAvailable(nsChannelListener * const 0x022e2be0,
nsIChannel * 0x022e2a30, nsISupports * 0x00000000, nsIInputStream * 0x022e3048,
unsigned int 0, unsigned int 98) line 1386
nsHTTPResponseListener::OnDataAvailable(nsHTTPResponseListener * const
0x022e3710, nsIChannel * 0x022e3d20, nsISupports * 0x022e2a30, nsIInputStream *
0x022e3048, unsigned int 0, unsigned int 98) line 186 + 47 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x022e03e0)
line 413
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x022e0320) line 169 + 12 bytes
PL_HandleEvent(PLEvent * 0x022e0320) line 526 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00672c40) line 487 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0087036c, unsigned int 49423, unsigned int 0,
long 6761536) line 961 + 9 bytes
USER32! 77e71250()
00672c40()
Status: NEW → ASSIGNED
Wonder how that happened!!. Anyway, I've some new changes in my tree that does
not cause a crash :).

Will investigate why the crash happened in the first place.
BTW, thanks for the reduced test case.
Blocks: 17432
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fixed the glitch in illegal-content handling code.

Marking FIXED.
Status: RESOLVED → VERIFIED
verified
No longer blocks: 17432
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: