Bug 105591 – REGRESSION (r138222?): Assertion failure on appcache/main-resource-redirect.html

• Component: Page Loading
• Status: RESOLVED FIXED

[Alexey Proskuryakov]

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.

[Brady Eidson]

Resources need to always have an identifier.

[Nate Chapin]

Created attachment 180537 [details]
patch

[Alexey Proskuryakov]

*** Bug 105691 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

*** Bug 105788 has been marked as a duplicate of this bug. ***

[Carlos Garcia Campos]

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

[Carlos Garcia Campos]

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.

[Brady Eidson]

Comment on attachment 180851 [details]
Different approach

I prefer this one over Nate's, though both are acceptable if tests pass, etc etc...

[Nate Chapin]

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.

[Chris Dumez]

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.

[Chris Dumez]

(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.

[Carlos Garcia Campos]

Committed r138782: <http://trac.webkit.org/changeset/138782>

[Ryosuke Niwa]

Apparently this crash hasn’t been fixed. See https://bugs.webkit.org/show_bug.cgi?id=106123.