To reproduce: 1. set-webkit-configuration --debug 2. run-webkit-tests plugins/return-negative-one-from-write.html You'll hit an assertion in ResourceHandle::setDefersLoading: ASSERT(d->m_defersLoading != defers); // Deferring is not counted, so calling setDefersLoading() repeatedly is likely to be in error. d->m_defersLoading and defers are both true. I don't know what the effect is in a Release build. The release test bot seems not to be crashing on this test, however. Here's the backtrace: > WebKit.dll!WebCore::ResourceHandle::setDefersLoading(bool defers=true) Line 148 + 0x36 bytes C++ WebKit.dll!WebCore::ResourceLoader::setDefersLoading(bool defers=true) Line 155 C++ WebKit.dll!WebCore::PluginStream::destroyStream() Line 271 + 0x22 bytes C++ WebKit.dll!WebCore::PluginStream::destroyStream(short reason=0x0001) Line 239 C++ WebKit.dll!WebCore::PluginStream::cancelAndDestroyStream(short reason=0x0001) Line 224 C++ WebKit.dll!WebCore::PluginStream::deliverData() Line 360 C++ WebKit.dll!WebCore::PluginStream::didReceiveData(WebCore::NetscapePlugInStreamLoader * loader=0x067a2138, const char * data=0x0684d9a8, int length=0x00000004) Line 432 C++ WebKit.dll!WebCore::NetscapePlugInStreamLoader::didReceiveData(const char * data=0x0684d9a8, int length=0x00000004, __int64 lengthReceived=0x0000000000000004, bool allAtOnce=false) Line 93 + 0x27 bytes C++ WebKit.dll!WebCore::ResourceLoader::didReceiveData(WebCore::ResourceHandle * __formal=0x06821da0, const char * data=0x0684d9a8, int length=0x00000004, int lengthReceived=0x00000004) Line 431 + 0x1f bytes C++ WebKit.dll!WebCore::didReceiveData(_CFURLConnection * conn=0x0ace0160, const __CFData * data=0x06780730, long originalLength=0x00000004, const void * clientInfo=0x06821da0) Line 214 + 0x2a bytes C++
It looks like the problem is in PluginStream::deliverData. <http://trac.webkit.org/browser/trunk/WebCore/plugins/PluginStream.cpp?rev=58590#L343> calls setDefersLoading(true), then <http://trac.webkit.org/browser/trunk/WebCore/plugins/PluginStream.cpp?rev=58590#L359> calls cancelAndDestroyStream, which ends up calling setDefersLoading(true) again beneath destroyStream. (There's actually another problem here: When we return early from deliverData at <http://trac.webkit.org/browser/trunk/WebCore/plugins/PluginStream.cpp?rev=58590#L360>, we never call setDefersLoading(false).)
This test has been asserting since it was added in r62739.
Calling setDefersLoading(false) just before calling cancelAndDestroyStream seems like it should fix the problem.
Created attachment 61949 [details] Patch
Committed r63667: <http://trac.webkit.org/changeset/63667>