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 (deleted) —
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: