Closed Bug 51383 Opened 25 years ago Closed 25 years ago

Mozilla Crashes when it detects a Doctype that it doesn't recognize

Categories

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

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 50994

People

(Reporter: mozilla, Assigned: rickg)

References

(
URL
)

Details

Using Mozilla build 20000901 I recieve a crash when I go to the following URL. http://www.psu.edu/ur/directory/ which is the gateway to Penn State's interactive directory. I did some snooping and found that the culprit was this line... <!DOCTYPE HTML PUBLIC "-//SoftQuad Software//DTD HoTMetaL PRO 6.0::19990601::extensions to HTML 4.0//EN" "hmpro6.dtd"> when I removed it, the page loaded perfectly and I didn't recieve an invalid page fault in the module gkparser. I don't know whether this error is because the file hmpro6.dtd is unavailable, or because it doesn't recognize the DTD. I couldn't find an exact match to this bug, although there are several similar. All I know is that mozilla shouldn't crash completly when faced with one line of bad HTML when the rest of the page is perfect.
I crashed too, talkback incident with comment "bug 51383" sent. Strangely enough it has no Incident ID in the "NQFA" window, despite its status being "Sent"...
dup of bug 50994 nsCParserNode::GetNodeType() line 232 + 12 bytes HTMLContentSink::CloseContainer(0x0135e080, {...}) line 3013 + 11 bytes CElement::CloseContainer(0x01349200, eHTMLTag_li, 0x01303c20, 0x0135e080) line 322 CElement::CloseContainerInContext(0x01349200, eHTMLTag_li, 0x01303c20, 0x0135e080) line 350 CElement::HandleStartToken(0x01365970, eHTMLTag_li, 0x01303c20, 0x0135e080) line 2773 CLIElement::HandleStartToken(0x01365970, eHTMLTag_li, 0x01303c20, 0x0135e080) line 997 COtherDTD::HandleStartToken(0x02d2dda8) line 784 + 33 bytes COtherDTD::HandleToken(0x013071a0, 0x02d2dda8, 0x0354f720) line 584 + 12 bytes COtherDTD::BuildModel(0x013071a0, 0x0354f720, 0x01303b00, 0x00000000, 0x0135e080) line 479 + 20 bytes nsParser::BuildModel() line 1978 + 34 bytes nsParser::ResumeParse(1, 0) line 1859 + 11 bytes nsParser::OnDataAvailable(0x0354f728, 0x03593030, 0x00000000, 0x0136a8e4, 0, 1549) line 2309 + 19 bytes nsDocumentOpenInfo::OnDataAvailable(0x03595c30, 0x03593030, 0x00000000, 0x0136a8e4, 0, 1549) line 251 + 46 bytes nsHTTPFinalListener::OnDataAvailable(0x03595bd0, 0x03593030, 0x00000000, 0x0136a8e4, 0, 1549) line 1188 + 46 bytes InterceptStreamListener::OnDataAvailable(0x0136a8e0, 0x03593030, 0x00000000, 0x0136ebf0, 0, 1549) line 1195 nsHTTPServerListener::OnDataAvailable(0x01368830, 0x01361234, 0x03593030, 0x0136ebf0, 1268, 1549) line 551 + 67 bytes nsOnDataAvailableEvent::HandleEvent(0x01308e00) line 400 + 47 bytes nsStreamListenerEvent::HandlePLEvent(0x01308db0) line 97 + 12 bytes PL_HandleEvent(0x01308db0) line 587 + 10 bytes PL_ProcessPendingEvents(0x010170f0) line 528 + 9 bytes _md_EventReceiverProc(0x000000a0, 58848, 0, 16871664) line 1043 + 9 bytes KERNEL32! bff7363b() KERNEL32! bff94407() 007989fe() *** This bug has been marked as a duplicate of 50994 ***
Status: UNCONFIRMED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
This is a dup of bug 50994:Crashing in nsCParserNode::GetNodeType, with strict DOCTYPE and unclosed tags
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.