Changeset 183178 in webkit


Ignore:
Timestamp:
Apr 23, 2015 12:57:57 AM (9 years ago)
Author:
Antti Koivisto
Message:

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.

Location:
trunk/Source/WebCore
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • trunk/Source/WebCore/ChangeLog

    r183175 r183178  
     12015-04-22  Antti Koivisto  <antti@apple.com>
     2
     3        CrashTracer: WebProcess at com.apple.WebCore: WebCore::toScriptElementIfPossible + 4
     4        https://bugs.webkit.org/show_bug.cgi?id=144050
     5        rdar://problem/15534973
     6
     7        Reviewed by Chris Dumez.
     8
     9        We are seeing null Element pointer crashes with this stack:
     10
     11        47 com.apple.WebCore:  WebCore::toScriptElementIfPossible + 4 <==
     12        47 com.apple.WebCore:  WebCore::ScriptRunner::timerFired + 452
     13        47 com.apple.WebCore:  WebCore::ThreadTimers::sharedTimerFiredInternal + 175
     14
     15        The most likely cause seems to be that this code
     16
     17            ASSERT(m_pendingAsyncScripts.contains(scriptElement));
     18            m_scriptsToExecuteSoon.append(m_pendingAsyncScripts.take(scriptElement));
     19
     20        in ScriptRunner::notifyScriptReady fails to find scriptElement and we are left with a null entry in
     21        m_scriptsToExecuteSoon. However I haven't managed to repro this or find the exact path how this
     22        could happen. The related code is fragile with lot of state (in ScriptElement class)
     23        and involves many opportunities for re-entry via scripts.
     24
     25        No repro, no test case.
     26
     27        * dom/ScriptRunner.cpp:
     28        (WebCore::ScriptRunner::timerFired):
     29
     30            Paper this over by adding a null check. We could check m_pendingAsyncScripts.take() above
     31            but this also covers possibility this is caused by something else.
     32
    1332015-04-23  Simon Fraser  <simon.fraser@apple.com>
    234
  • trunk/Source/WebCore/dom/ScriptRunner.cpp

    r181348 r183178  
    115115        CachedScript* cachedScript = scripts[i].cachedScript();
    116116        RefPtr<Element> element = scripts[i].releaseElementAndClear();
     117        ASSERT(element);
     118        // Paper over https://bugs.webkit.org/show_bug.cgi?id=144050
     119        if (!element)
     120            continue;
    117121        toScriptElementIfPossible(element.get())->execute(cachedScript);
    118122        m_document.decrementLoadEventDelayCount();
Note: See TracChangeset for help on using the changeset viewer.