fast/frames/frame-name-reset.html crashes on my Windows XP machine and on a build bot running Windows XP (see URL). When run in the debugger, the test outputs the ALERT message, then hangs for a while under CFNetwork code, then appears to crash due to memory corruption.
<http://build.webkit.org/builders/trunk-win-release/builds/6954> (@r29409) is the earliest run with this crash, because earlier runs crashed in an earlier test.
My untested theory of the day is that calling CFURLConnectionResume on a connection during one of that connection's callbacks results in the connection being over-released due to a bug in CFURLConnection. (In the test case, alert() is called under the data: URL's CFURLConnection's callback, and the chrome uses a PageGroupLoadDeferrer around the alert, which calls CFURLConnectionHalt and CFURLConnectionResume on the data: URL connection).
<rdar://problem/5686091>
(In reply to comment #2) > (In the test case, alert() > is called under the data: URL's CFURLConnection's callback I was wrong. It is called under the test's URL's (file:///cygwin/...) callback, so it is not immediately clear how the data: URL is involved. The file: URL connection is also halted and resumed, but that is expected to happen in any test that calls alert() before it is finished loading.
To test my theory, I added a CFRetain(d->m_connection.get()) in the !defers case of ResourceHandle::setDefersLoading(). After doing that, I could not reproduce the crash. I am not sure that the problem is over-releasing, though. It might be simply that there are still messages posted for the CFURLConnection on the queue when it is deallocated.
This reminds me of a crash that Alice was working on -- maybe she can shed some more light?
The problem is most probably in a non-WebKit component.