Closed
Bug 11948
Opened 25 years ago
Closed 25 years ago
[PP]XML crashes caused by DOCTYPE
Categories
(Core :: XML, defect, P1)
Tracking
()
M10
People
(Reporter: dbaron, Assigned: nisheeth_mozilla)
Details
(Whiteboard: 9/22: Requested verification by assigned or reporter)
Attachments
(3 files)
I think this is different from bug 10703. In builds 1999-08-13-08-M9 and 1999-08-14-08-M9, on apprunner and viewer, on Linux, certain DOCTYPE declarations in an XML file cause apprunner/viewer to terminate instantly without dumping core. What I'm seeing: (first attachment) This crashes: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/strict.dtd"> (second attachment) This gives an XML parsing error (as it should) but doesn't crash: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"> (third attachment) This works fine: <!DOCTYPE html> Either this is a recent change (last week) or it's a platform parity bug (Linux and not Windows) and last two weeks. The files worked for me on Linux a little over two weeks ago (I think) and on Windows roughly a week ago.
Reporter | ||
Comment 1•25 years ago
|
||
Reporter | ||
Comment 2•25 years ago
|
||
Reporter | ||
Comment 3•25 years ago
|
||
Reporter | ||
Updated•25 years ago
|
Priority: P3 → P1
Reporter | ||
Comment 4•25 years ago
|
||
Marking P1. I think this deserves it.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 5•25 years ago
|
||
Setting milestone to M10 and setting milestone to M10...
Assignee | ||
Updated•25 years ago
|
Target Milestone: M10
With the first attachment I get a crash with the following stack trace: NTDLL! 77f76148() nsDebug::Error(char * 0x030a0d20, char * 0x030a0ce8, int 190) line 204 + 13 bytes nsHTTPChannel::OpenInputStream(nsHTTPChannel * const 0x02b85e50, unsigned int 0, int -1, nsIInputStream * * 0x0012fa50) line 190 + 21 bytes NS_OpenURI(nsIInputStream * * 0x0012faf4, nsIURI * 0x02b857e0) line 79 + 20 bytes nsExpatTokenizer::OpenInputStream(const nsString & {"http://www.w3.org/TR/xhtml1/DTD/strict.dtd"}, const nsString & {"http://bugzilla.mozilla.org/showattachment.cgi?attach_id=1255"}, nsIInputStream * * 0x0012faf4, nsString * 0x0012fb1c {""}) line 530 + 13 bytes nsExpatTokenizer::HandleExternalEntityRef(void * 0x0138bda0, char * 0x00000000, char * 0x01386cd8, char * 0x01386d96, char * 0x01386d54) line 608 + 21 bytes doProlog(void * 0x0138bda0, const encoding * 0x01763838, char * 0x013879a6, char * 0x01387aba, int 17, char * 0x013879a8, char * * 0x0012fc20) line 2272 + 36 bytes prologProcessor(void * 0x0138bda0, char * 0x013878b0, char * 0x01387aba, char * * 0x0012fc20) line 2145 + 36 bytes prologInitProcessor(void * 0x0138bda0, char * 0x013878b0, char * 0x01387aba, char * * 0x0012fc20) line 2134 + 21 bytes XML_Parse(void * 0x0138bda0, char * 0x013878b0, int 522, int 0) line 867 + 40 bytes nsExpatTokenizer::ParseXMLBuffer(char * 0x013878b0, unsigned int 522, int 0) line 287 + 24 bytes nsExpatTokenizer::ConsumeToken(nsScanner & {...}) line 330 + 18 bytes nsParser::Tokenize(int 0) line 1264 + 21 bytes nsParser::ResumeParse(nsIDTD * 0x00000000, int 0) line 885 + 12 bytes nsParser::OnDataAvailable(nsParser * const 0x013cfefc, nsIChannel * 0x02da1550, nsISupports * 0x00000000, nsIInputStream * 0x02dadc30, unsigned int 0, unsigned int 261) line 1168 + 19 bytes nsDocumentBindInfo::OnDataAvailable(nsDocumentBindInfo * const 0x03363190, nsIChannel * 0x02da1550, nsISupports * 0x00000000, nsIInputStream * 0x02dadc30, unsigned int 0, unsigned int 261) line 2057 + 32 bytes nsHTTPResponseListener::OnDataAvailable(nsHTTPResponseListener * const 0x02dac2c0, nsIChannel * 0x02da1420, nsISupports * 0x02da1550, nsIInputStream * 0x02dadc30, unsigned int 0, unsigned int 261) line 163 + 47 bytes nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x02d88ab0) line 350 ... This got to be a duplicate of 10703.
Summary: XML crashes caused by DOCTYPE → [PP]XML crashes caused by DOCTYPE
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Comment 9•25 years ago
|
||
David, this is a dup of 10703 which is a dup of 10456. Your first test case attempts to access a DTD file on a remote host. This is currently not working because Necko does not support synchronous file loading. Once Rick Potts fixes bug 10456, this will begin to work. I'm marking this bug as a duplicate of bug 10456. *** This bug has been marked as a duplicate of 10456 ***
Updated•25 years ago
|
Whiteboard: 9/22: Requested verification by assigned or reporter
Comment 10•25 years ago
|
||
David or Nisheeth: I am unable to verify this as a dup of #10456. Isn't really a dependent bug? If you agree to 'dup' please mark verified. Thanks
Assignee | ||
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment hidden (collapsed) |
You need to log in
before you can comment on or make changes to this bug.
Description
•