Bug 150327 - ASSERTION FAILED: m_state == Initialized in SubresourceLoader::didReceiveResponse()
Summary: ASSERTION FAILED: m_state == Initialized in SubresourceLoader::didReceiveResp...
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
Keywords: Gtk, LayoutTestFailure
Depends on:
Reported: 2015-10-19 05:11 PDT by Carlos Garcia Campos
Modified: 2015-10-19 23:19 PDT (History)
4 users (show)

See Also:

Patch (3.55 KB, patch)
2015-10-19 05:16 PDT, Carlos Garcia Campos
koivisto: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Garcia Campos 2015-10-19 05:11:31 PDT
This happens with printing/print-close-crash.html in the GTK+ port. 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() si 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.
Comment 1 Carlos Garcia Campos 2015-10-19 05:16:45 PDT
Created attachment 263472 [details]
Comment 2 Carlos Garcia Campos 2015-10-19 23:19:19 PDT
Committed r191332: <http://trac.webkit.org/changeset/191332>