Summary: | fast/frames/frame-name-reset.html crashes Windows XP | ||
---|---|---|---|
Product: | WebKit | Reporter: | mitz |
Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED INVALID | ||
Severity: | Normal | CC: | alice.barraclough, aroben |
Priority: | P2 | Keywords: | InRadar, LayoutTestFailure |
Version: | 528+ (Nightly build) | ||
Hardware: | PC | ||
OS: | Windows XP | ||
URL: | http://build.webkit.org/builders/trunk-win-release/builds/6984 |
Description
mitz
2008-01-13 16:50:01 PST
<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). (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. |