Title: [183178] trunk/Source/WebCore
- Revision
- 183178
- Author
- [email protected]
- Date
- 2015-04-23 00:57:57 -0700 (Thu, 23 Apr 2015)
Log 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.
Modified Paths
Diff
Modified: trunk/Source/WebCore/ChangeLog (183177 => 183178)
--- trunk/Source/WebCore/ChangeLog 2015-04-23 07:47:07 UTC (rev 183177)
+++ trunk/Source/WebCore/ChangeLog 2015-04-23 07:57:57 UTC (rev 183178)
@@ -1,3 +1,35 @@
+2015-04-22 Antti Koivisto <[email protected]>
+
+ 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 <[email protected]>
Use a typedef for TileGrid tile validation policy flags
Modified: trunk/Source/WebCore/dom/ScriptRunner.cpp (183177 => 183178)
--- trunk/Source/WebCore/dom/ScriptRunner.cpp 2015-04-23 07:47:07 UTC (rev 183177)
+++ trunk/Source/WebCore/dom/ScriptRunner.cpp 2015-04-23 07:57:57 UTC (rev 183178)
@@ -114,6 +114,10 @@
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();
}
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
