Bug 49935 – Crash at WebCore::ScriptElementData::execute (AsyncScriptRunner's timer fires after the document is unloaded)

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: DOM

[Ryosuke Niwa]

Created attachment 74591 [details]
demo

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb1e5ab70 (LWP 9849)]
WebCore::ScriptElementData::execute (this=0x35c62f4, cachedScript=0x0) at third_party/WebKit/WebCore/dom/ScriptElement.cpp:219
219         if (cachedScript->errorOccurred())

#0  WebCore::ScriptElementData::execute (this=0x35c62f4, cachedScript=0x0) at third_party/WebKit/WebCore/dom/ScriptElement.cpp:219
#1  0x019e1d04 in WebCore::AsyncScriptRunner::timerFired (this=0x3588740, timer=0x3588750) at third_party/WebKit/WebCore/dom/AsyncScriptRunner.cpp:87
#2  0x019e17f1 in WebCore::Timer<WebCore::AsyncScriptRunner>::fired (this=0x35c62f4) at third_party/WebKit/WebCore/platform/Timer.h:98
#3  0x015d33b1 in WebCore::ThreadTimers::sharedTimerFiredInternal (this=0x32a5d00) at third_party/WebKit/WebCore/platform/ThreadTimers.cpp:112
#4  0x015d3495 in WebCore::ThreadTimers::sharedTimerFired () at third_party/WebKit/WebCore/platform/ThreadTimers.cpp:90
#5  0x01074882 in webkit_glue::WebKitClientImpl::DoTimeout (this=0x31d8e60) at ./webkit/glue/webkitclient_impl.h:68
#6  0x010749a7 in DispatchToMethod<webkit_glue::WebKitClientImpl, void (webkit_glue::WebKitClientImpl::*)()> (this=0x32a5b60) at ./base/tuple.h:537
#7  base::BaseTimer<webkit_glue::WebKitClientImpl, false>::TimerTask::Run (this=0x32a5b60) at ./base/timer.h:160
#8  0x009cc66b in MessageLoop::RunTask (this=0xb1e5a1dc, task=0x32a5b60) at base/message_loop.cc:418
#9  0x009cdc0e in MessageLoop::DeferOrRunPendingTask (this=0xb1e5a1dc, pending_task=...) at base/message_loop.cc:427
#10 0x009cdefc in MessageLoop::DoWork (this=0xb1e5a1dc) at base/message_loop.cc:534
#11 0x009cff20 in base::MessagePumpDefault::Run (this=0x3162400, delegate=0xb1e5a1dc) at base/message_pump_default.cc:23
#12 0x009cd134 in MessageLoop::RunInternal (this=0xb1e5a1dc) at base/message_loop.cc:266
#13 0x009cd25d in MessageLoop::RunHandler (this=0x35c62f4) at base/message_loop.cc:238
#14 MessageLoop::Run (this=0x35c62f4) at base/message_loop.cc:216
#15 0x009eff9d in base::Thread::Run (this=0x31276c0, message_loop=0xb1e5a1dc) at base/thread.cc:140
#16 0x009f05ab in base::Thread::ThreadMain (this=0x31276c0) at base/thread.cc:164
#17 0x009de951 in ThreadFunc (closure=0x31276c0) at base/platform_thread_posix.cc:35
#18 0xb75db96e in start_thread (arg=0xb1e5ab70) at pthread_create.c:300
#19 0xb7153a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Copied from http://crbug.com/63302

On TOT debug build, we hit the assertion in ScriptElement::notifyFinished:
void ScriptElement::notifyFinished(CachedResource* o)
{
    ASSERT_UNUSED(o, o == m_cachedScript);
    m_element->document()->asyncScriptRunner()->executeScriptSoon(this, m_cachedScript);
    m_cachedScript = 0;
}
which is added by http://trac.webkit.org/changeset/42665

[Ryosuke Niwa]

The timer seems to be firing after the script element has been removed from the document but I can't reproduce reliably.  In fact, attaching a breakpoint almost always prevent the crash from happening. We need some loader experts here.

[Ryosuke Niwa]

The problem is that we're calling notifyFinished in ScriptElement::requestScript because it does m_cachedScript->addClient(this), while notifyFinished is also called by didFinishLoading.

You can see the sequence of events as follows:

didFinishLoading: file:///Users/rniwa/Desktop/crbug63302.svg#bar
0x105f62c10: stopLoadRequest, 0x105f701a0
0x105f62c10: stopLoadRequest, 0x0
0x105f5fda0: requestScript, 0x0
    0x105f5fda0: notifyFinished, 0x105f701a0
0x105f5fda0: stopLoadRequest, 0x0
0x105f62c10: requestScript, 0x0
    0x105f62c10: notifyFinished, 0x105f701a0 < this call clears m_cachedScript
0x105f62c10: notifyFinished, 0x0 < oops! m_cachedScript is gone already
ASSERTION FAILED: o == m_cachedScript

I feel like ScriptElement::requestScript shouldn't be calling addClient but I'm not confident.  The stack trace for the first call to notifyFinished is:

#0	0x101fb02c0 in WebCore::ScriptElement::notifyFinished at ScriptElement.cpp:245
#1	0x101549f24 in WebCore::CachedResource::didAddClient at CachedResource.cpp:222
#2	0x10154b28b in WebCore::CachedResource::addClient at CachedResource.cpp:216
#3	0x101fb0655 in WebCore::ScriptElement::requestScript at ScriptElement.cpp:171
#4	0x101fb11f2 in WebCore::ScriptElement::insertedIntoDocument at ScriptElement.cpp:78
#5	0x1020c8737 in WebCore::SVGScriptElement::insertedIntoDocument at SVGScriptElement.cpp:99
#6	0x10159eb3a in WebCore::ContainerNode::insertedIntoDocument at ContainerNode.cpp:728
#7	0x1017f5ba2 in WebCore::Element::insertedIntoDocument at Element.cpp:858
#8	0x102054195 in WebCore::SVGElement::insertedIntoDocument at SVGElement.cpp:295
#9	0x1020d2d29 in WebCore::SVGStyledElement::insertedIntoDocument at SVGStyledElement.cpp:274
#10	0x1020f1089 in WebCore::SVGUseElement::insertedIntoDocument at SVGUseElement.cpp:125
#11	0x10159dcca in WebCore::notifyChildInserted at ContainerNode.cpp:1015
#12	0x10159ff99 in WebCore::ContainerNode::appendChild at ContainerNode.cpp:604
#13	0x1020f2c4b in WebCore::SVGUseElement::buildShadowTree at SVGUseElement.cpp:780
#14	0x1020f3699 in WebCore::SVGUseElement::buildShadowAndInstanceTree at SVGUseElement.cpp:538
#15	0x101f1d2ec in WebCore::RenderSVGShadowTreeRootContainer::updateFromElement at RenderSVGShadowTreeRootContainer.cpp:77
#16	0x1020f2de6 in WebCore::SVGUseElement::recalcStyle at SVGUseElement.cpp:346
#17	0x1017f5922 in WebCore::Element::recalcStyle at Element.cpp:1041
#18	0x1016d095c in WebCore::Document::recalcStyle at Document.cpp:1574
#19	0x1016d062f in WebCore::Document::updateStyleIfNeeded at Document.cpp:1616
#20	0x1016c949d in WebCore::Document::updateStyleForAllDocuments at Document.cpp:1633
#21	0x101fa639c in WebCore::ScriptController::executeScript at ScriptControllerBase.cpp:64
#22	0x102186d54 in WebCore::XMLDocumentParser::notifyFinished at XMLDocumentParser.cpp:362

[Ryosuke Niwa]

Notation for the output:
this: <function name>, m_cachedScript

[Alexey Proskuryakov]

<rdar://problem/8895819>

[Alexey Proskuryakov]

Actually, can you still reproduce this? I tried opening the demo in Safari/WebKit 5.0.3 and in r76045, but couldn't get a crash.

[Tony Gentilcore]

The test case doesn't repro for me either on r76356 (osx 10.6).

rniwa, please reopen if you still believe this to be an issue.