Closed Bug 38158 Opened 24 years ago Closed 24 years ago

XHTML with comment before processing instruction crashes browser

Categories

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

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 39520

People

(Reporter: moj, Assigned: harishd)

Details

(Keywords: crash)

Attachments

(2 files)

testcase causing crash
302 bytes, text/html
Details
same testcase but served as text/xml
312 bytes, text/xml
Details 
The following XHTML file crashes the browser:



<!-- Vignette StoryServer 4 Thu May 04 13:34:52 2000 -->

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http:

//www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

...

...



The mime type is text/html



/Mats-Olof
moj@vd.volvo.se - we need to know the build ID of your copy of Mozilla (bottom 
right corner of browser window) before we can go any further.

Gerv
fixing up as crash
Severity: minor → critical
Keywords: crash
Mozilla build no: 2000050308


Build ID: 2000050608

Does not actually crash the browser for me, but does make the html display
widget go 'weird'.  When I load the XHTML snippet I can 'paint' other windows
over the top of the html display widget and the widget is never redrawn.  The
surrounding menu bars, sidebar etc. are totally uneffected, and I can load
another url just fine immediately afterwards.
Confirming bug and changing component to "Parser" and reassigning since file is
served as text/html (and is therefore handled by the HTML Parser's Strict DTD).

Stack trace (from debug build from tree closure of 2000-05-16):

#0  0x413e5de6 in HTMLContentSink::CreateContentObject (this=0x878a2e8, 
    aNode=@0xbfffef4c, aNodeType=eHTMLTag_parsererror, aForm=0x0, 
    aWebShell=0x0, aResult=0xbfffeef4) at nsHTMLContentSink.cpp:1061
#1  0x413e7012 in SinkContext::OpenContainer (this=0x8736a10, 
    aNode=@0xbfffef4c) at nsHTMLContentSink.cpp:1356
#2  0x413ec670 in HTMLContentSink::OpenContainer (this=0x878a2e8, 
    aNode=@0xbfffef4c) at nsHTMLContentSink.cpp:3015
#3  0x41865c30 in CWellFormedDTD::HandleStartToken (this=0x870c8f0, 
    aToken=0x8369d30) at nsWellFormedDTD.cpp:616
#4  0x41865e3c in CWellFormedDTD::HandleErrorToken (this=0x870c8f0, 
    aToken=0x87437e8) at nsWellFormedDTD.cpp:676
#5  0x4186581e in CWellFormedDTD::HandleToken (this=0x870c8f0, 
    aToken=0x87437e8, aParser=0x8718298) at nsWellFormedDTD.cpp:505
#6  0x418653b0 in CWellFormedDTD::BuildModel (this=0x870c8f0, 
    aParser=0x8718298, aTokenizer=0x8742130, anObserver=0x0, aSink=0x878a2e8)
    at nsWellFormedDTD.cpp:257
#7  0x41857d6f in nsParser::BuildModel (this=0x8718298) at nsParser.cpp:1664
#8  0x41857b05 in nsParser::ResumeParse (this=0x8718298, allowIteration=1, 
    aIsFinalChunk=0) at nsParser.cpp:1548
#9  0x4185886a in nsParser::OnDataAvailable (this=0x8718298, 
    channel=0x876beb0, aContext=0x0, pIStream=0x85aa858, sourceOffset=0, 
    aLength=302) at nsParser.cpp:1982
...
Assignee: nisheeth → rickg
Status: UNCONFIRMED → NEW
Component: XML → Parser
Ever confirmed: true
QA Contact: chrisd → janc
BTW, note that the testcase is not well-formed XML, since the XML declaration
must be the first thing in the document if it is present.
Are we certain that the bug occured using the StrictDTD? 
Ahh -- this isn't the strict DTD at all; it's the wellformed (XML) dtd. The 
strictDTD *should* be used but it's not because the xml pi and doctypes are 
misplaced. I can have a trivial fix for this tomorrow.

Requesting beta2 status, given the simple nature of the fix.
Status: NEW → ASSIGNED
Keywords: nsbeta2
Does that mean that if that file was served up as text/xml it would also crash?
Let's see...
Nisheeth, here's a crasher for you. The attached testcase is a valid xml 
document, except that it starts with a comment -- then crashes.
Assignee: rickg → nisheeth
Status: ASSIGNED → NEW
Harish, one more crash related to a page that has an XML error.  Your 
changes will probably fix this one also.  Here is the call stack:

memcpy(unsigned char * 0x029fece8, unsigned char * 0x00000000, unsigned long 
312) line 171
nsByteArrayInputStream::Read(nsByteArrayInputStream * const 0x0338b950, char * 
0x029fece8, unsigned int 312, unsigned int * 0x0012f900) line 72 + 34 bytes
InterceptStreamListener::Read(InterceptStreamListener * const 0x03ba60b4, char * 
0x029fece8, unsigned int 312, unsigned int * 0x0012f900) line 1177 + 38 bytes
nsParser::OnDataAvailable(nsParser * const 0x03bad338, nsIChannel * 0x03b93e70, 
nsISupports * 0x00000000, nsIInputStream * 0x03ba60b4, unsigned int 0, unsigned 
int 312) line 1840 + 30 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x03b912f0, 
nsIChannel * 0x03b93e70, nsISupports * 0x00000000, nsIInputStream * 0x03ba60b4, 
unsigned int 0, unsigned int 312) line 189 + 46 bytes
nsHTTPFinalListener::OnDataAvailable(nsHTTPFinalListener * const 0x03b93d90, 
nsIChannel * 0x03b93e70, nsISupports * 0x00000000, nsIInputStream * 0x03ba60b4, 
unsigned int 0, unsigned int 312) line 1217 + 46 bytes
InterceptStreamListener::OnDataAvailable(InterceptStreamListener * const 
0x03ba60b0, nsIChannel * 0x03b93e70, nsISupports * 0x00000000, nsIInputStream * 
0x0338b950, unsigned int 0, unsigned int 312) line 1165
nsHTTPChunkConv::OnDataAvailable(nsHTTPChunkConv * const 0x0297cd30, nsIChannel 
* 0x03b93e70, nsISupports * 0x00000000, nsIInputStream * 0x03b1304c, unsigned 
int 0, unsigned int 5) line 208 + 46 bytes
nsHTTPServerListener::OnDataAvailable(nsHTTPServerListener * const 0x03b10f70, 
nsIChannel * 0x03b06ee4, nsISupports * 0x03b93e70, nsIInputStream * 0x03b1304c, 
unsigned int 514, unsigned int 5) line 540 + 67 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x03ba9b60) 
line 406 + 47 bytes
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x03ba9b10) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x03ba9b10) line 575 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x0148df50) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x01ed0560, unsigned int 49367, unsigned int 0, 
long 21552976) line 1030 + 9 bytes
USER32! 77e71820()
0148df50()
Assignee: nisheeth → harishd
Ian's attachment ( 2000-05-18 02:02 ) displays an XML error [ Checked in a fix 
for XML error display, that got regressed a week back, yesterday].  However, 
David's attachment causes a crash. Rickg, has a fix in hand for the crash and 
will be checking in soon.  

*** This bug has been marked as a duplicate of 39520 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
verified dup
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: