Title: [191332] trunk/Source/WebCore
- Revision
- 191332
- Author
- [email protected]
- Date
- 2015-10-19 23:18:15 -0700 (Mon, 19 Oct 2015)
Log Message
ASSERTION FAILED: m_state == Initialized in SubresourceLoader::didReceiveResponse()
https://bugs.webkit.org/show_bug.cgi?id=150327
Reviewed by Antti Koivisto.
This is how it happens:
1. print() is called while the document is still loading, so
m_shouldPrintWhenFinishedLoading is set to true
2. DataURLDecoder::decode() finishes in the work queue thread,
the completion handler is scheduled in the main thread
3. The load is cancelled
3.1. SubresourceLoader::willCancel sets m_state = Finishing
3.2. DOMWindow::finishedLoading() is called, and since
m_shouldPrintWhenFinishedLoading is true, it does the print.
3.3. Cancellation finishes and ResourceLoader::releaseResources()
is called that sets m_reachedTerminalState = true
So, between 3.1 and 3.3, the state is Finishing, but
m_reachedTerminalState is false. What happens, in the GTK+ port at
least, is that the nested main loop used to make print()
synchronous, processes the DataURLDecoder::decode() completion
handler that was pending. The completion handler returns early if
m_reachedTerminalState is true, but it's not yet in this
particular case. So, it ends up calling didReceiveResponse,
because the decode didn't fail, when the subresource loader state
is Finishing.
I think there are two things here. One is that we shouldn't start
a print that was waiting for the load to finish when it
failed. That would fix the problem. But it's probably a good idea
to also check for cancellation in the DataURLDecoder::decode()
completion handler.
Fixes printing/print-close-crash.html in GTK+ Debug.
* loader/ResourceLoader.cpp:
(WebCore::ResourceLoader::loadDataURL): Return early from
DataURLDecoder::decode() completion handler if the load was cancelled.
* page/DOMWindow.cpp:
(WebCore::DOMWindow::finishedLoading): Do not start a print that
was witing for the load to finish when it failed.
Modified Paths
Diff
Modified: trunk/Source/WebCore/ChangeLog (191331 => 191332)
--- trunk/Source/WebCore/ChangeLog 2015-10-20 04:55:27 UTC (rev 191331)
+++ trunk/Source/WebCore/ChangeLog 2015-10-20 06:18:15 UTC (rev 191332)
@@ -1,3 +1,48 @@
+2015-10-19 Carlos Garcia Campos <[email protected]>
+
+ ASSERTION FAILED: m_state == Initialized in SubresourceLoader::didReceiveResponse()
+ https://bugs.webkit.org/show_bug.cgi?id=150327
+
+ Reviewed by Antti Koivisto.
+
+ This is how it happens:
+
+ 1. print() is called while the document is still loading, so
+ m_shouldPrintWhenFinishedLoading is set to true
+ 2. DataURLDecoder::decode() finishes in the work queue thread,
+ the completion handler is scheduled in the main thread
+ 3. The load is cancelled
+ 3.1. SubresourceLoader::willCancel sets m_state = Finishing
+ 3.2. DOMWindow::finishedLoading() is called, and since
+ m_shouldPrintWhenFinishedLoading is true, it does the print.
+ 3.3. Cancellation finishes and ResourceLoader::releaseResources()
+ is called that sets m_reachedTerminalState = true
+
+ So, between 3.1 and 3.3, the state is Finishing, but
+ m_reachedTerminalState is false. What happens, in the GTK+ port at
+ least, is that the nested main loop used to make print()
+ synchronous, processes the DataURLDecoder::decode() completion
+ handler that was pending. The completion handler returns early if
+ m_reachedTerminalState is true, but it's not yet in this
+ particular case. So, it ends up calling didReceiveResponse,
+ because the decode didn't fail, when the subresource loader state
+ is Finishing.
+
+ I think there are two things here. One is that we shouldn't start
+ a print that was waiting for the load to finish when it
+ failed. That would fix the problem. But it's probably a good idea
+ to also check for cancellation in the DataURLDecoder::decode()
+ completion handler.
+
+ Fixes printing/print-close-crash.html in GTK+ Debug.
+
+ * loader/ResourceLoader.cpp:
+ (WebCore::ResourceLoader::loadDataURL): Return early from
+ DataURLDecoder::decode() completion handler if the load was cancelled.
+ * page/DOMWindow.cpp:
+ (WebCore::DOMWindow::finishedLoading): Do not start a print that
+ was witing for the load to finish when it failed.
+
2015-10-19 Myles C. Maxfield <[email protected]>
FontCascade::typesettingFeatures() is not privy to font-variant-* nor font-feature-settings
Modified: trunk/Source/WebCore/loader/ResourceLoader.cpp (191331 => 191332)
--- trunk/Source/WebCore/loader/ResourceLoader.cpp 2015-10-20 04:55:27 UTC (rev 191331)
+++ trunk/Source/WebCore/loader/ResourceLoader.cpp 2015-10-20 06:18:15 UTC (rev 191332)
@@ -256,6 +256,8 @@
loader->didFail(ResourceError(errorDomainWebKitInternal, 0, url.string(), "Data URL decoding failed"));
return;
}
+ if (loader->wasCancelled())
+ return;
auto& result = decodeResult.value();
auto dataSize = result.data->size();
Modified: trunk/Source/WebCore/page/DOMWindow.cpp (191331 => 191332)
--- trunk/Source/WebCore/page/DOMWindow.cpp 2015-10-20 04:55:27 UTC (rev 191331)
+++ trunk/Source/WebCore/page/DOMWindow.cpp 2015-10-20 06:18:15 UTC (rev 191332)
@@ -1987,7 +1987,8 @@
{
if (m_shouldPrintWhenFinishedLoading) {
m_shouldPrintWhenFinishedLoading = false;
- print();
+ if (m_frame->loader().activeDocumentLoader()->mainDocumentError().isNull())
+ print();
}
}
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
