CrashTracer: WebProcess at com.apple.WebCore: WebCore::toScriptElementIfPossible + 4
authorantti@apple.com <antti@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 23 Apr 2015 07:57:57 +0000 (07:57 +0000)
committerantti@apple.com <antti@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 23 Apr 2015 07:57:57 +0000 (07:57 +0000)
commita9c5a66741a276e1cfdd5e78ba8a3b64a1fcd208
tree422281ac093d9415140a1583f9ae970c0b77cee4
parenta4bb4aa63bcd5deae67be6ab47d4c3182ed34ee0
CrashTracer: WebProcess at com.apple.WebCore: WebCore::toScriptElementIfPossible + 4
https://bugs.webkit.org/show_bug.cgi?id=144050
rdar://problem/15534973

Reviewed by Chris Dumez.

We are seeing null Element pointer crashes with this stack:

47 com.apple.WebCore:  WebCore::toScriptElementIfPossible + 4 <==
47 com.apple.WebCore:  WebCore::ScriptRunner::timerFired + 452
47 com.apple.WebCore:  WebCore::ThreadTimers::sharedTimerFiredInternal + 175

The most likely cause seems to be that this code

    ASSERT(m_pendingAsyncScripts.contains(scriptElement));
    m_scriptsToExecuteSoon.append(m_pendingAsyncScripts.take(scriptElement));

in ScriptRunner::notifyScriptReady fails to find scriptElement and we are left with a null entry in
m_scriptsToExecuteSoon. However I haven't managed to repro this or find the exact path how this
could happen. The related code is fragile with lot of state (in ScriptElement class)
and involves many opportunities for re-entry via scripts.

No repro, no test case.

* dom/ScriptRunner.cpp:
(WebCore::ScriptRunner::timerFired):

    Paper this over by adding a null check. We could check m_pendingAsyncScripts.take() above
    but this also covers possibility this is caused by something else.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@183178 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebCore/ChangeLog
Source/WebCore/dom/ScriptRunner.cpp