Bug 162484 - WebCore::ResourceErrorBase::setType is crashing
Summary: WebCore::ResourceErrorBase::setType is crashing
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: youenn fablet
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-23 01:41 PDT by youenn fablet
Modified: 2018-08-14 11:14 PDT (History)
6 users (show)

See Also:


Attachments
Patch (5.34 KB, patch)
2016-09-23 01:58 PDT, youenn fablet
no flags Details | Formatted Diff | Diff
Patch (8.88 KB, patch)
2016-09-28 05:39 PDT, youenn fablet
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description youenn fablet 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
Comment 1 youenn fablet 2016-09-23 01:58:16 PDT
Created attachment 289672 [details]
Patch
Comment 2 youenn fablet 2016-09-23 10:43:07 PDT
<rdar://problem/28390828>
Comment 3 Alex Christensen 2016-09-27 08:56:54 PDT
Comment on attachment 289672 [details]
Patch

No test?
Comment 4 youenn fablet 2016-09-28 05:39:49 PDT
Created attachment 290078 [details]
Patch
Comment 5 youenn fablet 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.
Comment 6 WebKit Commit Bot 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>
Comment 7 WebKit Commit Bot 2016-09-28 09:39:52 PDT
All reviewed patches have been landed.  Closing bug.
Comment 8 Basuke Suzuki 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.
Comment 9 youenn fablet 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.
Comment 10 Basuke Suzuki 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.