Bug 101416 – Assertion failure in SubresourceLoader::didFail when reloading

• Status: RESOLVED
• Resolution: FIXED
• Component: Page Loading

[KyungTae Kim]

Crash occurred when SubresourceLoader::didFail called during reload by ASSERT(!m_resource->resourceToRevalidate())
The m_resource->m_resourceToRevalidate was set by CachedResource::setResourceToRevalidate on request,
and was expected to clear by CachedResource::clearResourceToRevalidate when responce received.

CachedResourceLoader::requestResource
 CachedResourceLoader::revalidateResource
  CachedResource::setResourceToRevalidate

SubresourceLoader::didReceiveResponse
 MemoryCache::revalidationSucceeded  (or MemoryCache::revalidationFailed)
  CachedResource::clearResourceToRevalidate

But, when  SubresourceLoader::didFail called by ResourceLoader::didFail, there was no chance to clear before that.
sendRequestCallback
 ResourceLoader::didFail
  SubresourceLoader::didFail

So, in this case, clear the resourceToRevalidate on there would be more suitable than ASSERT.

[KyungTae Kim]

Created attachment 172688 [details]
Patch

[Nate Chapin]

(In reply to comment #0)
> Crash occurred when SubresourceLoader::didFail called during reload by ASSERT(!m_resource->resourceToRevalidate())
> The m_resource->m_resourceToRevalidate was set by CachedResource::setResourceToRevalidate on request,
> and was expected to clear by CachedResource::clearResourceToRevalidate when responce received.
> 
> CachedResourceLoader::requestResource
>  CachedResourceLoader::revalidateResource
>   CachedResource::setResourceToRevalidate
> 
> SubresourceLoader::didReceiveResponse
>  MemoryCache::revalidationSucceeded  (or MemoryCache::revalidationFailed)
>   CachedResource::clearResourceToRevalidate
> 
> But, when  SubresourceLoader::didFail called by ResourceLoader::didFail, there was no chance to clear before that.
> sendRequestCallback
>  ResourceLoader::didFail
>   SubresourceLoader::didFail
> 
> So, in this case, clear the resourceToRevalidate on there would be more suitable than ASSERT.

Please provide a complete stack trace, and a test case if possible. I don't have enough context from this description to be sure that this is the correct fix.

Thanks!

[KyungTae Kim]

I found it on Webkit2 EFL MiniBrowser.
The test case was.. 
1) enter some site - and all the subresource downloaded successfully
2) reload  - and  one of the subresource downloaded failed
3) WebProcess crash occurred by the ASSERT fail

This is rare case, and I couldn't make layout test for that.

The site I found it is :
 http://media.daum.net/photo/5662#20121107080810714
The below subresource didFail when reload :
http://s1.daumcdn.net/photo-media/static/media/3.6.3/dist/media/news_photo.min.css

The backtrace was like the below :

#0  0x00007f82a6ab4485 in WebCore::SubresourceLoader::didFail (this=0x198e870, error=...) at Source/WebCore/loader/SubresourceLoader.cpp:285
#1  0x00007f82a6aaf7bb in WebCore::ResourceLoader::didFail (this=0x198e870, error=...) at Source/WebCore/loader/ResourceLoader.cpp:460
#2  0x00007f82a75f99cc in WebCore::sendRequestCallback (res=0x1cb5420, data=0x1b315b0) at Source/WebCore/platform/network/soup/ResourceHandleSoup.cpp:437
#3  0x00007f82a28aea8d in g_simple_async_result_complete (simple=0x1cb5420) at gsimpleasyncresult.c:767
#4  0x00007f82a23a0676 in http_input_stream_ready_cb (source=0x163c010, result=0x20462e0, user_data=0x17740c0) at soup-request-http.c:139
#5  0x00007f82a28aea8d in g_simple_async_result_complete (simple=0x20462e0) at gsimpleasyncresult.c:767
#6  0x00007f82a23a7fbb in send_request_return_result (stream=<optimized out>, error=<optimized out>, item=<optimized out>) at soup-session-async.c:522
#7  0x00007f82a23a8256 in try_run_until_read (item=0x7f8244003190) at soup-session-async.c:670
#8  0x00007f82a23a826c in read_ready_cb (msg=<optimized out>, user_data=<optimized out>) at soup-session-async.c:644
#9  0x00007f82a2be0e53 in g_main_dispatch (context=0x1780340) at gmain.c:2539
#10 g_main_context_dispatch (context=0x1780340) at gmain.c:3075
#11 0x00007f82a3b3016e in _ecore_glib_select__locked (ecore_timeout=0x1780340, efds=<optimized out>, wfds=<optimized out>, rfds=<optimized out>, ecore_fds=5, ctx=<optimized out>) at ecore_glib.c:171
#12 _ecore_glib_select (ecore_fds=5, rfds=<optimized out>, wfds=<optimized out>, efds=<optimized out>, ecore_timeout=0x1780340) at ecore_glib.c:205
#13 0x00007f82a3b29dc9 in _ecore_main_select (timeout=<optimized out>) at ecore_main.c:1444
#14 0x00007f82a3b2a955 in _ecore_main_loop_iterate_internal (once_only=0) at ecore_main.c:1872
#15 0x00007f82a3b2ac57 in ecore_main_loop_begin () at ecore_main.c:934
#16 0x00007f82a75de5b1 in WebCore::RunLoop::run () at Source/WebCore/platform/efl/RunLoopEfl.cpp:90
#17 0x00007f82aa7cb8b6 in WebKit::WebProcessMainEfl (argc=2, argv=0x7fff9502acf8) at Source/WebKit2/WebProcess/efl/WebProcessMainEfl.cpp:126
#18 0x0000000000400794 in main (argc=2, argv=0x7fff9502acf8) at Source/WebKit2/efl/MainEfl.cpp:30

[Nate Chapin]

Hmm, it is pretty rare to have a revalidation attempt trigger didFail() when the original request didn't.

For a reproducible layout test, my first thought is:

Request a subresource, which includes a "Cache-Control: no-store, no-cache, must-revalidate" header.

Request it again, but this time it redirects to http://localhost:7, which should reliably trigger a didFail().

I'm especially curious to know whether this crashes happens on all ports. I can't tell from inspection whether sendRequestCallback() is calling didFail() at the correct time.

[Alexey Proskuryakov]

> Hmm, it is pretty rare to have a revalidation attempt trigger didFail() when the original request didn't.

Probably occurs when network is down. We have a "network down" simulating script somewhere in http/tests for testing applications cache. It might help here, too.

[Alexey Proskuryakov]

Comment on attachment 172688 [details]
Patch

r- for the lack of a test case.

[Alexey Proskuryakov]

Created attachment 181966 [details]
proposed fix

[Alexey Proskuryakov]

Committed <http://trac.webkit.org/changeset/139230>.