Bug 16866 – fast/frames/frame-name-reset.html crashes Windows XP

• Component: New Bugs
• Status: RESOLVED INVALID

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.

[Adam Roben (:aroben)]

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.