Possible crash in void ProgressTracker::progressHeartbeatTimerFired(Timer<ProgressTracker>*) We know that it is possible to crash in ProgressTracker::progressHeartbeatTimerFired(Timer<ProgressTracker>*) with a null m_originatingProgressFrame. On the surface it appears this should not be possible because any time m_originatingProgressFrame is cleared out the progress heartbeat timer is also stopped. It is likely a race condition with stopping the timer in multi-threaded environments, yet we still have no way to reproduce. There's no harm in null checking m_originatingProgressFrame before calling in to its loader.
Created attachment 218223 [details] Patch v1
Comment on attachment 218223 [details] Patch v1 While there is no harm in adding a null check, if this is actually a race condition, then a null check is likely not sufficient to fix the problem. It might, however, reduce the frequency of a crash.
(In reply to comment #2) > (From update of attachment 218223 [details]) > While there is no harm in adding a null check, if this is actually a race condition, then a null check is likely not sufficient to fix the problem. It might, however, reduce the frequency of a crash. Agreed. Based on looking at disassembly this is our only theory on what's going on, so a more comprehensive fix isn't presenting itself yet. Landed in http://trac.webkit.org/changeset/159974
This null check might have been incorrect
More specifically, ProgressTracker::progressHeartbeatTimerFired(Timer<ProgressTracker>*) might be calling in to a valid m_originatingProgressFrame (and its valid loader), but in FrameLoader::loadProgressingStatusChanged() we might have a null FrameView.
Created attachment 218237 [details] Patch v2 - Also null check a FrameView
Created attachment 218238
http://trac.webkit.org/changeset/159986
<rdar://problem/15217862>