fast/xmlhttprequest/xmlhttprequest-responsetype-arraybuffer.html is crashing on Windows. Test only sometimes crashes release. Seems to crash debug more often.
Added to skipped list in http://trac.webkit.org/changeset/78672
<rdar://problem/9008719>
Steve, do you have a stack trace for the crash?
00 0012f09c 01a8e111 WebKit!WebCore::TextCodecUTF8::decode(char * bytes = 0x0b6ce008 "(???", unsigned int length = 0x10000, bool flush = false, bool stopOnError = false, bool * sawError = 0x0b51c358)+0xb8 [c:\cygwin\home\buildbot\slave\win-debug\build\source\webcore\platform\text\textcodecutf8.cpp @ 171] 01 0012f108 01a3017b WebKit!WebCore::TextResourceDecoder::decode(char * data = 0x0b6ce008 "(???", unsigned int len = 0x10000)+0x221 [c:\cygwin\home\buildbot\slave\win-debug\build\source\webcore\loader\textresourcedecoder.cpp @ 658] 02 0012f18c 01e5c973 WebKit!WebCore::XMLHttpRequest::didReceiveData(char * data = 0x0b6ce008 "(???", int len = 0n65536)+0x2ab [c:\cygwin\home\buildbot\slave\win-debug\build\source\webcore\xml\xmlhttprequest.cpp @ 1078] 03 0012f1a4 01d17e16 WebKit!WebCore::DocumentThreadableLoader::didReceiveData(class WebCore::SubresourceLoader * loader = 0x0a4e1d30, char * data = 0x0b6ce008 "(???", int lengthReceived = 0n65536)+0xe3 [c:\cygwin\home\buildbot\slave\win-debug\build\source\webcore\loader\documentthreadableloader.cpp @ 231] 04 0012f1cc 01901cee WebKit!WebCore::SubresourceLoader::didReceiveData(char * data = 0x0b6ce008 "(???", int length = 0n65536, int64 lengthReceived = 0n65536, bool allAtOnce = false)+0x86 [c:\cygwin\home\buildbot\slave\win-debug\build\source\webcore\loader\subresourceloader.cpp @ 158] 05 0012f200 0189eb4a WebKit!WebCore::ResourceLoader::didReceiveData(class WebCore::ResourceHandle * __formal = 0x0b51c960, char * data = 0x0b6ce008 "(???", int length = 0n65536, int lengthReceived = 0n65536)+0x5e [c:\cygwin\home\buildbot\slave\win-debug\build\source\webcore\loader\resourceloader.cpp @ 430] 06 0012f230 007dbe06 WebKit!WebCore::didReceiveData(struct _CFURLConnection * conn = 0x0b50e0c8, struct __CFData * data = 0x0aa2a4b0, long originalLength = 0n65536, void * clientInfo = 0x0b51c960)+0xda [c:\cygwin\home\buildbot\slave\win-debug\build\source\webcore\platform\network\cf\resourcehandlecfnet.cpp @ 211] 07 0012f274 007dc4a2 CFNetwork!URLConnectionClient::_clientDidReceiveData+0xa9 08 0012f37c 007dcf0b CFNetwork!URLConnectionClient::ClientConnectionEventQueue::processAllEventsAndConsumePayload+0x211 09 0012f38c 007dc6cd CFNetwork!XConnectionEventQueue<enum XLoaderEvent,XLoaderEventParams>::processAllEvents+0x14 0a 0012f3a0 007da495 CFNetwork!URLConnectionClient::processEvents+0x44 0b 0012f3ac 7e418734 CFNetwork!MirroredSet::contains+0x5b 0c 0012f3d8 7e418816 USER32!InternalCallWinProc+0x28 0d 0012f440 7e4189cd USER32!UserCallWinProcCheckWow+0x150 0e 0012f4a0 7e418a10 USER32!DispatchMessageWorker+0x306 0f 0012f4b0 004572bd USER32!DispatchMessageW+0xf 10 0012f624 004560ee DumpRenderTree!runTest(class std::basic_string<char,std::char_traits<char>,std::allocator<char> > * testPathOrURL = 0x0012f69c)+0x72d [c:\cygwin\home\buildbot\slave\win-debug\build\tools\dumprendertree\win\dumprendertree.cpp @ 993] 11 0012ff7c 00464fef DumpRenderTree!main(int argc = 0n2, char ** argv = 0x045a9f70)+0x8ce [c:\cygwin\home\buildbot\slave\win-debug\build\tools\dumprendertree\win\dumprendertree.cpp @ 1370] 12 0012ffc0 7c817077 DumpRenderTree!__tmainCRTStartup(void)+0x10f [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 597] 13 0012fff0 00000000 kernel32!BaseProcessStart+0x23
Crash is in WebCore::TextCodecUTF8::decode
Line 171 is: ASSERT(count > m_partialSequenceSize);
This could be what Darin described in bug 54444 comment 3: "if a partial sequence is invalid, then the remainder of that is left as a partial sequence. But the remainder could contain plain ASCII characters, and the code does not handle that path correctly." Looks like ArrayBuffer isn't enabled on Windows (unlike Mac), and that's what is making the test try to decode the binary response as text and execute a buggy code path. It should be easy to make this happen on Mac by modifying the test to not set responseType.
See also: bug 54862.
I believe <http://trac.webkit.org/changeset/79466> fixed this. Please let me know if this turns out to be the case.