Looks like <http://trac.webkit.org/r138222> made it so that a delegate is called for a resource with 0 identifier on this test, so a crash happens when accessing a HashMap. Nate, can you please take a look? Note the test is currently also affected by an unrelated regression, tracked as bug 105563.
Resources need to always have an identifier.
Created attachment 180537 [details] patch
*** Bug 105691 has been marked as a duplicate of this bug. ***
*** Bug 105788 has been marked as a duplicate of this bug. ***
Comment on attachment 180537 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=180537&action=review > Source/WebCore/loader/MainResourceLoader.cpp:594 > + m_substituteDataLoadIdentifier = m_documentLoader->frame()->page()->progress()->createUniqueIdentifier(); > + frameLoader()->notifier()->assignIdentifierToInitialRequest(m_substituteDataLoadIdentifier, documentLoader(), m_initialRequest); > + frameLoader()->notifier()->dispatchWillSendRequest(documentLoader(), m_substituteDataLoadIdentifier, m_initialRequest, ResourceResponse()); In case of redirection a new identifier will be created, and assignIdentifierToInitialRequest() will be called twice, this request is not the initial one, but the redirected one, shouldn't we consider it like the same resource and keep the identifier? See the patch I attached to bug #105788
Created attachment 180851 [details] Different approach In case of redirect, assignIdentifierToInitialRequest has already been called for the resource, if the redirect is going to be loaded from the app cache reuse the identifier and continue the load.
Comment on attachment 180851 [details] Different approach I prefer this one over Nate's, though both are acceptable if tests pass, etc etc...
Comment on attachment 180851 [details] Different approach View in context: https://bugs.webkit.org/attachment.cgi?id=180851&action=review > Source/WebCore/loader/MainResourceLoader.cpp:273 > + if (m_substituteData.isValid()) > + m_substituteDataLoadIdentifier = identifier(); I don't know if this was tested in debug, but it's possible that this will assert when identifier() is called later, since it asserts that either m_substituteDataLoadIdentifer or ResourceLoader::identiifer() will be 0. Please verify before landing if you haven't already done so.
Comment on attachment 180851 [details] Different approach View in context: https://bugs.webkit.org/attachment.cgi?id=180851&action=review >> Source/WebCore/loader/MainResourceLoader.cpp:273 >> + m_substituteDataLoadIdentifier = identifier(); > > I don't know if this was tested in debug, but it's possible that this will assert when identifier() is called later, since it asserts that either m_substituteDataLoadIdentifer or ResourceLoader::identiifer() will be 0. Please verify before landing if you haven't already done so. Yes, I verified that this patch fixed http/tests/appcache/main-resource-redirect.html for a debug build of WebKit2 EFL. I'll do a layout tests run though to make sure there are no regressions.
(In reply to comment #9) > (From update of attachment 180851 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=180851&action=review > > >> Source/WebCore/loader/MainResourceLoader.cpp:273 > >> + m_substituteDataLoadIdentifier = identifier(); > > > > I don't know if this was tested in debug, but it's possible that this will assert when identifier() is called later, since it asserts that either m_substituteDataLoadIdentifer or ResourceLoader::identiifer() will be 0. Please verify before landing if you haven't already done so. > > Yes, I verified that this patch fixed http/tests/appcache/main-resource-redirect.html for a debug build of WebKit2 EFL. I'll do a layout tests run though to make sure there are no regressions. I did a full layout tests run with a debug build. The patch does not seem to cause regressions on EFL WK2.
Committed r138782: <http://trac.webkit.org/changeset/138782>
Apparently this crash hasn’t been fixed. See https://bugs.webkit.org/show_bug.cgi?id=106123.