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)
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

index 0b8a139..db6b9b1 100644 (file)
@@ -1,3 +1,35 @@
+2015-04-22  Antti Koivisto  <antti@apple.com>
+
+        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.
+
 2015-04-23  Simon Fraser  <simon.fraser@apple.com>
 
         Use a typedef for TileGrid tile validation policy flags
index d628a2c..9636980 100644 (file)
@@ -114,6 +114,10 @@ void ScriptRunner::timerFired()
     for (size_t i = 0; i < size; ++i) {
         CachedScript* cachedScript = scripts[i].cachedScript();
         RefPtr<Element> element = scripts[i].releaseElementAndClear();
+        ASSERT(element);
+        // Paper over https://bugs.webkit.org/show_bug.cgi?id=144050
+        if (!element)
+            continue;
         toScriptElementIfPossible(element.get())->execute(cachedScript);
         m_document.decrementLoadEventDelayCount();
     }