Bug 10022 – REGRESSION: Crash in WebCore::XMLTokenizer::characters

• Component: XML
• Status: RESOLVED FIXED

[Jon]

You may need to refresh the page to get the crash as it seems to successfully load sometimes. 

Thread 0 Crashed:
0   com.apple.WebCore        	0x010429c4 WebCore::XMLTokenizer::characters(unsigned char const*, int) + 148 (XMLTokenizer.cpp:861)
1   com.apple.WebCore        	0x01045a10 WebCore::XMLTokenizer::resumeParsing() + 64 (DeprecatedPtrList.h:53)
2   com.apple.WebCore        	0x01045cd4 WebCore::XMLTokenizer::notifyFinished(WebCore::CachedResource*) + 484 (XMLTokenizer.cpp:1320)
3   com.apple.WebCore        	0x0112f618 WebCore::CachedScript::checkNotify() + 88 (CachedScript.cpp:109)
4   com.apple.WebCore        	0x0112facc WebCore::CachedScript::data(WTF::Vector<char, (unsigned long)0>&, bool) + 236 (CachedScript.cpp:101)
5   com.apple.WebCore        	0x01131c9c WebCore::Loader::receivedAllData(WebCore::TransferJob*, NSData*) + 300 (loader.cpp:139)
6   com.apple.WebCore        	0x0104b394 -[WebCoreResourceLoaderImp finishJobAndHandle:] + 116 (WebCoreResourceLoaderImp.mm:98)
7   com.apple.WebKit         	0x00325490 -[WebSubresourceLoader didFinishLoading] + 80
8   com.apple.WebKit         	0x0032728c -[WebLoader connectionDidFinishLoading:] + 44 (WebLoader.m:575)
9   com.apple.Foundation     	0x9297684c -[NSURLConnection(NSURLConnectionInternal) _sendDidFinishLoadingCallback] + 188
10  com.apple.Foundation     	0x92974ab8 -[NSURLConnection(NSURLConnectionInternal) _sendCallbacks] + 556
11  com.apple.Foundation     	0x92974810 _sendCallbacks + 156
12  com.apple.CoreFoundation 	0x907dc4cc __CFRunLoopDoSources0 + 384
13  com.apple.CoreFoundation 	0x907db9fc __CFRunLoopRun + 452
14  com.apple.CoreFoundation 	0x907db47c CFRunLoopRunSpecific + 268
15  com.apple.HIToolbox      	0x931eb740 RunCurrentEventLoopInMode + 264
16  com.apple.HIToolbox      	0x931eadd4 ReceiveNextEventCommon + 380
17  com.apple.HIToolbox      	0x931eac40 BlockUntilNextEventMatchingListInMode + 96
18  com.apple.AppKit         	0x936eeae4 _DPSNextEvent + 384
19  com.apple.AppKit         	0x936ee7a8 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 116
20  com.apple.SafariDev      	0x00006740 0x1000 + 22336
21  com.apple.AppKit         	0x936eacec -[NSApplication run] + 472
22  com.apple.AppKit         	0x937db87c NSApplicationMain + 452
23  com.apple.SafariDev      	0x0005c77c 0x1000 + 374652
24  com.apple.SafariDev      	0x0005c624 0x1000 + 374308

[Mark Rowe (bdash)]

Confirmed with r15536.

[Mark Rowe (bdash)]

The page in question has an HTML 4.0 doctype, yet claims to be application/xhtml+xml via the Content-Type meta tag.  This causes WebKit to attempt to process the HTML 4.0 document using the XML tokenizer.  A lot of the code in XMLTokenizer makes the assumption that m_currentNode is non-NULL, and this crash is caused by a violation of that assumption.

[Mark Rowe (bdash)]

Ok, so the website tricked me.  It returns HTML 4.0 by default unless the browser advertises support for application/xhtml+xml.  The XHTML page validates fine, so there must be a more insidious bug hiding somewhere.

[Mark Rowe (bdash)]

Created attachment 9578 [details]
Patch

Occasionally when parsing is paused and then resumed, data may have arrived that when parsed causes callbacks to be queued.  If XMLTokenizer::finish() has been called while the parser was paused, then we call end() to clean up the parse.  This results in the current node being cleared, which causes a crash when the callbacks are finally processed.

[Mark Rowe (bdash)]

I should note that I intend to write an HTTP layout test for this later this evening, but it may be tricky to find the exact sequence of data arrival that will easily trigger the bug.

[Darin Adler]

Comment on attachment 9578 [details]
Patch

Is there a way to make a test for this bug? The fix looks OK, but I'd we normally require a regression test for each fix.

[Darin Adler]

Comment on attachment 9578 [details]
Patch

I see the answer now.

r=me

[Darin Adler]

Committed revision 15689.