Title: [235992] trunk/Source/WebKit
- Revision
- 235992
- Author
- [email protected]
- Date
- 2018-09-13 15:32:33 -0700 (Thu, 13 Sep 2018)
Log Message
WebPageProxy::reportPageLoadResult can crash on some code paths
https://bugs.webkit.org/show_bug.cgi?id=189568
Reviewed by Chris Dumez.
WebPageProxy::reportPageLoadResult (which is called from
WebPageProxy::didFinishLoadForFrame) can sometimes crash when
accessing m_pageLoadStart (a std::optional) in its unloaded state.
Normally, m_pageLoadStart is initialized in
WebPageProxy::didStartProvisionalLoadForFrame, which one would expect
would be called before WebPageProxy::didFinishLoadForFrame. But that
turns out to not always be the case. It's not apparent under what
conditions didStartProvisionalLoadForFrame will not be called, but
it's happening in the wild, leading to crashes now that std::optional
asserts in release builds on bad accesses (see
https://bugs.webkit.org/show_bug.cgi?id=189568).
Fix this by checking m_pageLoadState on entry to reportPageLoadResult.
* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::didFailProvisionalLoadForFrame):
(WebKit::WebPageProxy::didFinishLoadForFrame):
(WebKit::WebPageProxy::didFailLoadForFrame):
(WebKit::WebPageProxy::reportPageLoadResult):
Modified Paths
Diff
Modified: trunk/Source/WebKit/ChangeLog (235991 => 235992)
--- trunk/Source/WebKit/ChangeLog 2018-09-13 22:28:30 UTC (rev 235991)
+++ trunk/Source/WebKit/ChangeLog 2018-09-13 22:32:33 UTC (rev 235992)
@@ -1,3 +1,30 @@
+2018-09-13 Keith Rollin <[email protected]>
+
+ WebPageProxy::reportPageLoadResult can crash on some code paths
+ https://bugs.webkit.org/show_bug.cgi?id=189568
+
+ Reviewed by Chris Dumez.
+
+ WebPageProxy::reportPageLoadResult (which is called from
+ WebPageProxy::didFinishLoadForFrame) can sometimes crash when
+ accessing m_pageLoadStart (a std::optional) in its unloaded state.
+ Normally, m_pageLoadStart is initialized in
+ WebPageProxy::didStartProvisionalLoadForFrame, which one would expect
+ would be called before WebPageProxy::didFinishLoadForFrame. But that
+ turns out to not always be the case. It's not apparent under what
+ conditions didStartProvisionalLoadForFrame will not be called, but
+ it's happening in the wild, leading to crashes now that std::optional
+ asserts in release builds on bad accesses (see
+ https://bugs.webkit.org/show_bug.cgi?id=189568).
+
+ Fix this by checking m_pageLoadState on entry to reportPageLoadResult.
+
+ * UIProcess/WebPageProxy.cpp:
+ (WebKit::WebPageProxy::didFailProvisionalLoadForFrame):
+ (WebKit::WebPageProxy::didFinishLoadForFrame):
+ (WebKit::WebPageProxy::didFailLoadForFrame):
+ (WebKit::WebPageProxy::reportPageLoadResult):
+
2018-09-13 Chris Dumez <[email protected]>
ProcessSwap.BackWithoutSuspendedPage API test hits assertion under WebPageProxy::didCreateMainFrame()
Modified: trunk/Source/WebKit/UIProcess/WebPageProxy.cpp (235991 => 235992)
--- trunk/Source/WebKit/UIProcess/WebPageProxy.cpp 2018-09-13 22:28:30 UTC (rev 235991)
+++ trunk/Source/WebKit/UIProcess/WebPageProxy.cpp 2018-09-13 22:32:33 UTC (rev 235992)
@@ -888,8 +888,7 @@
m_isClosed = true;
- if (m_pageLoadStart)
- reportPageLoadResult(ResourceError { ResourceError::Type::Cancellation });
+ reportPageLoadResult(ResourceError { ResourceError::Type::Cancellation });
if (m_activePopupMenu)
m_activePopupMenu->cancelTracking();
@@ -3463,8 +3462,7 @@
m_pageLoadState.clearPendingAPIRequestURL(transaction);
if (frame->isMainFrame()) {
- if (m_pageLoadStart)
- reportPageLoadResult(ResourceError { ResourceError::Type::Cancellation });
+ reportPageLoadResult(ResourceError { ResourceError::Type::Cancellation });
m_pageLoadStart = MonotonicTime::now();
m_pageLoadState.didStartProvisionalLoad(transaction, url, unreachableURL);
pageClient().didStartProvisionalLoadForMainFrame();
@@ -7911,7 +7909,8 @@
{ CompletionCondition::Timeout, Seconds::infinity(), DiagnosticLoggingKeys::timedOutKey() }
});
- ASSERT(m_pageLoadStart);
+ if (!m_pageLoadStart)
+ return;
auto pageLoadTime = MonotonicTime::now() - *m_pageLoadStart;
m_pageLoadStart = std::nullopt;
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
