185285 - crash opening invalid xml file that has stylesheet [@ nsXMLContentSink::GetCurrentContent]

Status: RESOLVED WORKSFORME

(Core :: XML, defect)

Description

[Tuukka Hastrup]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021210 Debian/1.2.1-3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021210 Debian/1.2.1-3

Mozilla crashes always if I visit an XML document similar to the example URL. 
AFAIK the document is invalid as it has multiple top-level elements. It seems
the first element needs to give stylesheet information, but it doesn't matter
whether the stylesheet file exists or not.


Reproducible: Always

Steps to Reproduce:
1. Open the example URL.


Actual Results:  
Segmentation fault.

Expected Results:  
Display parser error message.

debugger says the crash was at 
0x409c497d in NSGetModule () from /usr/lib/mozilla/components/libgkcontent.so

Comment 1

[Junk_HbJ]

Also crashes for me with 2002121308/Win98SE.
Talkback ID is TB15075421W

Comment 2

[Andrew Schultz]

Attachment: stacktrace

Assertion failure: count, at nsXMLContentSink.cpp:1310

Comment 3

[Andrew Schultz]

confirmed with linux trunk build 20021213

Comment 4

[Andrew Schultz]

marking NEW for real

Comment 5

[Heikki Toivonen (remove -bugzilla when emailing directly)]

After a bit of testing this seems to happen only when the XHTML link element is
the root element. If I surround link with any arbitrary element there is no
crash, and the parser will report the error regardint the second root tag.
xml-stylesheet PI does not cause crash in a similar situation. It does not
matter whether or not there is reallya stylesheet at the URL.

I also noticed that if there is only the link tag, the parser will report an
error that there is no element in the document, which is also wrong.

Based on this and the assertions I see it looks like the link element is
improperly removed from the document which is causing these problems.

Comment 6

[Heikki Toivonen (remove -bugzilla when emailing directly)]

See also bug 185808.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Attachment: the testcase....

Comment 8

[Boris Zbarsky [:bzbarsky]]

Well, there is one obvious issue here.  CloseElement is actually failing, since
NS_ERROR_HTMLPARSER_BLOCK is a failure code.  Then HandleEndElement never sets
the state to InEpilog, and things are all wacky.

Now if I fix the problem in CloseElement like so:

       rv = ssle->UpdateStyleSheet(nsnull, nsnull);
       if (rv == NS_ERROR_HTMLPARSER_BLOCK && mParser) {
         mParser->BlockParser();
+        rv = NS_OK;
       }
     }
   }

I still get a crash as follows:

Assertion failure: eXMLContentSinkState_InEpilog != mState, at
/home/bzbarsky/mozilla/debug/mozilla/content/xml/document/src/nsXMLContentSink.cpp:1689
Program /home/bzbarsky/mozilla/debug/obj-debug/dist/bin/mozilla-bin (pid =
19540) received signal 6.

(since this is a PR_ASSERT and PR_ASSERT is fatal).

If I replace the bogus <link> with with <x/> instead, I get a normal XML parse
error complaining about garbage after document end.  I sorta wonder why this
error is not produced in this case, but I suspect it has to do with style
loading's parser-blocking shenanigans.  We should revisit this once those are fixed.

Comment 9

[Chris Veenboer]

Mozilla 1.5 Windows XP

This also happens with the xml-stylesheet element (view
http://www.interdictor.org/dumpid/sys.xml).

Comment 10

[Neil Paris]

Crash on the testcase. Moz 1.7 Beta: Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.7b) Gecko/20040316

Talkback ID is TB10878X
Captured at 04/02/04 at 04:57 PM

Comment 11

[Boris Zbarsky [:bzbarsky]]

Um.. We know exactly where this crashes; the bug has a stack and all.

Comment 12

[Neil Paris]

Boris, Sorry for above spam (and this too). Removing CC.

Comment 13

[Ronald Tilby]

URL and the testcase.... both WFM using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060529 Minefield/3.0a1 ID:2006052910 [cairo]

Comment 14

[Andrew Schultz]

this started working between linux seamonkey trunk builds 2005-12-17-00 and 2005-12-18-04, probably bug 274777.

resolving WFM

Comment 15

[Jesse Ruderman]

Crashtest added as part of http://hg.mozilla.org/mozilla-central/rev/afc662d52ab1