| Summary: | Assertion failure in FrameLoader::checkLoadComplete() | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Alexey Proskuryakov <ap> | ||||
| Component: | Page Loading | Assignee: | Alexey Proskuryakov <ap> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | Keywords: | InRadar | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Mac | ||||||
| OS: | OS X 10.6 | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 29692 | ||||||
| Attachments: |
|
||||||
Created attachment 47147 [details]
proposed fix
Committed <http://trac.webkit.org/changeset/53655>. |
I'm frequently seeing assertion failure in FrameLoader::checkLoadComplete(): ASSERT(m_client->hasWebView()); I couldn't make a test case, but the sequence of events if roughly as follows: - a subframe is detached (FrameLoader::detachFromParent is called); - this results in a Frame::pageDestroyed() call (which is a lie, as Page is not destroyed); - after a while, FrameLoader's checkTimer fires; - since Frame::m_page is null now, m_client->hasWebView() returns false. This doesn't always happen, because usually, Frame is destructed before checkTimer has a chance to fire, canceling the timer. But Frame destruction is not totally deterministic, and I see Frame::m_lifeSupportTimer timer sometimes keep it alive long enough for FrameLoader::checkTimer to fire.