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
•