219006 - PR_ASSERT(eXMLContentSinkState_InEpilog != mState); [@ nsXMLContentSink::CloseElement ]

Status: VERIFIED DUPLICATE of bug 265184

(Core :: XML, defect)

Description

[timeless]

NTDLL! DbgBreakPoint address 0x77f9f9df
nsXMLContentSink::HandleStartElement(nsXMLContentSink * const 0x0cd89b80, const
unsigned short * 0x0ccc51c6, const unsigned short * * 0x0cc65288, unsigned int
1, unsigned int 4294967295, unsigned int 70) line 1691 + 32 bytes
nsXBLContentSink::HandleStartElement(nsXBLContentSink * const 0x0cd89b80, const
unsigned short * 0x0ccc51c6, const unsigned short * * 0x0cc65288, unsigned int
1, unsigned int 4294967295, unsigned int 70) line 236 + 29 bytes
nsExpatDriver::HandleStartElement(const unsigned short * 0x0ccc51c6, const
unsigned short * * 0x0cc65288) line 355
Driver_HandleStartElement(void * 0x0cce59a0, const char * 0x0ccc51c6, const char
* * 0x0cc65288) line 68 + 16 bytes
doContent(void * 0x0cc454c8, int 0, const encoding * 0x071a02a0
little2_encoding, const char * 0x0cd632b0, const char * 0x0cd63c0a, const char *
* 0x0012f438) line 1417 + 30 bytes
contentProcessor(void * 0x0cc454c8, const char * 0x0cd623fc, const char *
0x0cd63c0a, const char * * 0x0012f438) line 1112 + 30 bytes
doProlog(void * 0x0cc454c8, const encoding * 0x071a02a0 little2_encoding, const
char * 0x0cd623fc, const char * 0x0cd63c0a, int 29, const char * 0x0cd623fc,
const char * * 0x0012f438) line 2396 + 21 bytes
prologProcessor(void * 0x0cc454c8, const char * 0x0cd623fa, const char *
0x0cd63c0a, const char * * 0x0012f438) line 2254 + 36 bytes
XML_Parse(void * 0x0cc454c8, const char * 0x0cd623fa, int 6160, int 0) line 926
+ 40 bytes
nsExpatDriver::ParseBuffer(const char * 0x0cd623fa, unsigned int 6160, int 0)
line 816 + 24 bytes
nsExpatDriver::ConsumeToken(nsExpatDriver * const 0x0cce59a4, nsScanner & {...},
int & 0) line 925 + 32 bytes
nsParser::Tokenize(int 1) line 2575 + 26 bytes
nsParser::ResumeParse(int 1, int 1, int 1) line 1771 + 31 bytes
nsParser::ContinueParsing(nsParser * const 0x0cd863f8) line 1370 + 19 bytes
CSSLoaderImpl::SheetComplete(SheetLoadData * 0x0ccfd7b0, int 1) line 1507

Comment 1

[timeless]

Attachment: weirdal's crasher

Comment 2

[Alex Vincent [:WeirdAl]]

Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.5b) Gecko/20030909

Comment 3

[Adam Hauner]

It's crashing also 1.4.1 RC and 1.5 branch builds (in fact, it's crashing all).

Comment 4

[Alex Vincent [:WeirdAl]]

Attachment: reduced testcase (violates XBL spec)

Comment 6

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

The worry here is that we should never, ever even hit that assert. Like the
comment says, the parser should prevent this from happening. Why are we
executing this piece of code now? Rather than mask the problem, I'd rather
figure out the real problem and fix it.

Comment 7

[timeless]

well, you've had 6 months to figure it out, there's a simplified testcase which
will crash your browser. i'd like to at least prevent the stable branch from
quiting when it encounters this content.

Comment 8

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

Sorry for misleading comment... should have said: "Rather than mask the problem,
whyt don't *you* figure out the real problem and fix it." I haven't had much
time for Mozilla since last summer and this looks like it would take more time
than I have available...

But if you are only proposing doing the hack on a stable branch I guess I could
live with that. If this hack is done on the trunk it will mean nobody will ever
figure out what is causing it, I would guess...

Comment 9

[timeless]

Comment on attachment 147238 [details]
 

@@ -1148,7 +1148,8 @@ nsXMLContentSink::HandleEndElement(const
copy + paste error

Comment 10

[timeless]

nsINodeInfo was null.

nsXMLContentSink::CloseElement 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/xml/document
/src/nsXMLContentSink.cpp, line 539]
nsXMLContentSink::HandleEndElement 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/xml/document
/src/nsXMLContentSink.cpp, line 1161]
nsXBLContentSink::HandleEndElement 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/xbl/src/nsXB
LContentSink.cpp, line 382]
nsExpatDriver::HandleEndElement 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/htmlparser/src/nsExp
atDriver.cpp, line 373]
Driver_HandleEndElement 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/htmlparser/src/nsExp
atDriver.cpp, line 79]
doContent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/expat/xmlparse/xmlpa
rse.c, line 1509]
contentProcessor 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/expat/xmlparse/xmlpa
rse.c, line 1113]
doProlog 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/expat/xmlparse/xmlpa
rse.c, line 2401]
prologProcessor 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/expat/xmlparse/xmlpa
rse.c, line 2255]
MOZ_XML_Parse 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/expat/xmlparse/xmlpa
rse.c, line 927]
nsExpatDriver::ParseBuffer 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/htmlparser/src/nsExp
atDriver.cpp, line 839]
nsExpatDriver::ConsumeToken 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/htmlparser/src/nsExp
atDriver.cpp, line 948]
nsParser::Tokenize 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/htmlparser/src/nsPar
ser.cpp, line 2564]
nsParser::ResumeParse 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/htmlparser/src/nsPar
ser.cpp, line 1760]
nsParser::ContinueParsing 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/htmlparser/src/nsPar
ser.cpp, line 1360]

(this stack was from winEmbed).

Comment 11

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Blake, timeless says this is near your area.  Feel free to take it if you have
time before I do ;).

Comment 12

[Blake Kaplan (:mrbkap) (inactive)]

I took a 5 minute look at this. I saw that the XBL content sink sees the error
and sets its internal state in error, but doesn't bother telling the XML content
sink. In fact there's a big honkin' XXX comment at the top of
nsXBLContentSink::ReportUnexpectedElement that says as much. I didn't go any
further than that (I shouldn't have even spent 5 minutes on this in the first
place...) so I'm not sure *precisely* how the XML content sink ended up in the
epilog state. I'll try to look at this again sometime soon.

As a random question, what should we render if there's an XBL error (but not an
XML error). In other words, if we make ReportUnexpectedElement() tell the XML
content sink about its problems, what should happen?

Comment 13

[Blake Kaplan (:mrbkap) (inactive)]

Taking since I'm investigating. From code inspection (i.e., not using a
debugger), the problem is that the XBL content sink ends up in an error state
(mState == eXBL_Error). Note that we don't allow <implementation> to be pushed
onto the content stack in the XML content sink. Therefore, when we reach the
illegal <handlers>, the stack looks like this:
<window>
  <bindings>
    <binding>
      <!-- No <implementation> -->

In nsXBLContentSink::HandleEndElement, the sink uses its internal state to
determine whether or not to actually tell the XML content sink to pop the
content off of its stack (so, if the state is eXBL_Implementation and the
element being closed is </implementation> we don't tell the XML content sink to
do anything). However, once there's an error, we never hit this branch, and we
tell the XML content sink to close the container. In this case, it pops the last
one off (which is <binding>) and we are off by one for every other element, so
when we close </bindings> it closes <window> and puts us into the epilog state
(which we aren't in!) so we assert on trying to open <html:style>.

One way of wallpapering over this would be to do unconditional checks in
nsXBLContentSink::HandleEndElement for <implementation> and the other tags we
don't open on the stack. A better solution would be to figure out how error
handling in the XBL content sink should work (should it stop parsing altogether?
should it try to recover?).

As a side note, shouldn't nsXMLContentSink::HandleEndElement assert that the
content it just popped off had a tag name equal to aTagName? I suppose it
doesn't since XML requires this, but it can happen here and cause a (sort of)
unrelated assert later.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Looks like a dup of bug 265184 (that one's filed later, but has patch and all,
as well as a more to-the-point summary).

Comment 15

[Blake Kaplan (:mrbkap) (inactive)]

Nice to see I was on the right track :-).

*** This bug has been marked as a duplicate of 265184 ***