RESOLVED FIXED Bug 162484
WebCore::ResourceErrorBase::setType is crashing
https://bugs.webkit.org/show_bug.cgi?id=162484
Summary WebCore::ResourceErrorBase::setType is crashing
youenn fablet
Reported 2016-09-23 01:41:13 PDT
Log is: 1 com.apple.JavaScriptCore 0x011936c4 WTFCrash + 36 (Assertions.cpp:323) > 2 com.apple.WebCore 0x0207faef WebCore::ResourceErrorBase::setType(WebCore::ResourceErrorBase::Type) + 111 (ResourceErrorBase.cpp:63) 3 com.apple.WebCore 0x0042100a WebCore::CrossOriginPreflightChecker::notifyFinished(WebCore::CachedResource*) + 186 (CrossOriginPreflightChecker.cpp:95) 4 com.apple.WebCore 0x0026e76d WebCore::CachedResource::checkNotify() + 125 (CachedResource.cpp:380) 5 com.apple.WebCore 0x0026ea7f WebCore::CachedResource::error(WebCore::CachedResource::Status) + 143 (CachedResource.cpp:408) 6 com.apple.WebCore 0x023fee39 WebCore::SubresourceLoader::didFail(WebCore::ResourceError const&) + 377 (SubresourceLoader.cpp:527) 7 com.apple.WebKit 0x00a10288 WebKit::WebResourceLoader::didFailResourceLoad(WebCore::ResourceError const&) + 408 (WebResourceLoader.cpp:172) 8 com.apple.WebKit 0x00a14a36 void IPC::callMemberFunctionImpl<WebKit::WebResourceLoader, void (WebKit::WebResourceLoader::*)(WebCore::ResourceError const&), std::__1::tuple<WebCore::ResourceError>, 0ul>(WebKit::WebResourceLoader*, void (WebKit::WebResourceLoader::*)(WebCore::ResourceError const&), std::__1::tuple<WebCore::ResourceError>&&, std::__1::integer_sequence<unsigned long, 0ul>) + 150 (HandleMessage.h:16) 9 com.apple.WebKit 0x00a148a8 void IPC::callMemberFunction<WebKit::WebResourceLoader, void (WebKit::WebResourceLoader::*)(WebCore::ResourceError const&), std::__1::tuple<WebCore::ResourceError>, std::__1::integer_sequence<unsigned long, 0ul> >(std::__1::tuple<WebCore::ResourceError>&&, WebKit::WebResourceLoader*, void (WebKit::WebResourceLoader::*)(WebCore::ResourceError const&)) + 88 (HandleMessage.h:22) 10 com.apple.WebKit 0x00a13ce6 void IPC::handleMessage<Messages::WebResourceLoader::DidFailResourceLoad, WebKit::WebResourceLoader, void (WebKit::WebResourceLoader::*)(WebCore::ResourceError const&)>(IPC::Decoder&, WebKit::WebResourceLoader*, void (WebKit::WebResourceLoader::*)(WebCore::ResourceError const&)) + 262 (HandleMessage.h:102) 11 com.apple.WebKit 0x00a13432 WebKit::WebResourceLoader::didReceiveWebResourceLoaderMessage(IPC::Connection&, IPC::Decoder&) + 770 (WebResourceLoaderMessageReceiver.cpp:67) 12 com.apple.WebKit 0x002ffafd WebKit::NetworkProcessConnection::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 157 (NetworkProcessConnection.cpp:60) 13 com.apple.WebKit 0x000ba11
Attachments
Patch (5.34 KB, patch)
2016-09-23 01:58 PDT, youenn fablet
no flags
Patch (8.88 KB, patch)
2016-09-28 05:39 PDT, youenn fablet
no flags
youenn fablet
Comment 1 2016-09-23 01:58:16 PDT
youenn fablet
Comment 2 2016-09-23 10:43:07 PDT
Alex Christensen
Comment 3 2016-09-27 08:56:54 PDT
Comment on attachment 289672 [details] Patch No test?
youenn fablet
Comment 4 2016-09-28 05:39:49 PDT
youenn fablet
Comment 5 2016-09-28 05:42:06 PDT
(In reply to comment #3) > Comment on attachment 289672 [details] > Patch > > No test? I added one in the latest patch. It is taking a long time since it requires the network library to return a timeout error. Let's see whether the bots will like it or not... Ideally, the test infrastructure should be able to generate this kind of errors.
WebKit Commit Bot
Comment 6 2016-09-28 09:39:47 PDT
Comment on attachment 290078 [details] Patch Clearing flags on attachment: 290078 Committed r206524: <http://trac.webkit.org/changeset/206524>
WebKit Commit Bot
Comment 7 2016-09-28 09:39:52 PDT
All reviewed patches have been landed. Closing bug.
Basuke Suzuki
Comment 8 2018-08-10 21:58:49 PDT
youenn, question about the patch. Is the point of the test you've added in this patch that XHR should has a default timeout shorter than long timeout (150000)? Is the default timeout 60 sec? Is this timeout connection timeout or idle timeout or entire transaction timeout? I guess the third one, time limit for entire transaction.
youenn fablet
Comment 9 2018-08-13 13:01:18 PDT
(In reply to Basuke Suzuki from comment #8) > youenn, question about the patch. > Is the point of the test you've added in this patch that XHR should has a > default timeout shorter than long timeout (150000)? Yes. We want to trigger a timeout network error that ends up into a timeout XHR event. The test timeout should be bigger than the network timeout. > Is the default timeout 60 sec? > > Is this timeout connection timeout or idle timeout or entire transaction > timeout? I guess the third one, time limit for entire transaction. This is not really specified and might be dependent on the underlying network stack. In Mac/iOS, I believe it is the idle timeout.
Basuke Suzuki
Comment 10 2018-08-14 10:44:23 PDT
(In reply to youenn fablet from comment #9) > (In reply to Basuke Suzuki from comment #8) > > youenn, question about the patch. > > Is the point of the test you've added in this patch that XHR should has a > > default timeout shorter than long timeout (150000)? > > Yes. > We want to trigger a timeout network error that ends up into a timeout XHR > event. > The test timeout should be bigger than the network timeout. > > > Is the default timeout 60 sec? > > > > Is this timeout connection timeout or idle timeout or entire transaction > > timeout? I guess the third one, time limit for entire transaction. > > This is not really specified and might be dependent on the underlying > network stack. > In Mac/iOS, I believe it is the idle timeout. It seems this one, right? https://developer.apple.com/documentation/foundation/nsurlrequest/1418229-timeoutinterval Also from this line: https://github.com/WebKit/webkit/blob/master/Source/WebCore/loader/CrossOriginAccessControl.cpp#L82 I learned timeout with zero value means using platform default timeout. This was my prepared next question which I thought this meant no timeout.
Note You need to log in before you can comment on or make changes to this bug.