Chrome on iOS has been getting reports of 10+ second hangs in stringByResolvingSymlinksInPath, during the call to realpath. In many of these reports, another thread is making a filesystem-related call (e.g. fstatat, rmdir, rename) at the same time (initiated by code in Chrome) as the main thread is calling into stringByResolvingSymlinksInPath. Here's a sample stack: 0x00000001de364cf4 (libsystem_kernel.dylib + 0x00001cf4) __getattrlist 0x00000001b18cde20 (libsystem_c.dylib + 0x00012e20) realpath$DARWIN_EXTSN 0x00000001b55c5850 (WebKit + 0x001aa850) WebKit::stringByResolvingSymlinksInPath(WTF::String const&) 0x00000001b55c5960 (WebKit + 0x001aa960) WebKit::resolveAndCreateReadWriteDirectoryForSandboxExtension(WTF::String const&) 0x00000001b5ac5d70 (WebKit + 0x006aad70) WebKit::WebsiteDataStore::resolveDirectoriesIfNecessary() 0x00000001b5acf670 (WebKit + 0x006b4670) WebKit::WebsiteDataStore::parameters() 0x00000001b5acf5d4 (WebKit + 0x006b45d4) WebKit::WebsiteDataStore::parametersFromEachWebsiteDataStore() 0x00000001b5a85940 (WebKit + 0x0066a940) WebKit::NetworkProcessProxy::sendCreationParametersToNewProcess() 0x00000001b5a85f5c (WebKit + 0x0066af5c) WebKit::NetworkProcessProxy::NetworkProcessProxy() 0x00000001b5a84ff8 (WebKit + 0x00669ff8) WebKit::NetworkProcessProxy::ensureDefaultNetworkProcess() 0x00000001b5ac5b48 (WebKit + 0x006aab48) WebKit::WebsiteDataStore::networkProcess() 0x00000001b5ac678c (WebKit + 0x006ab78c) WebKit::WebsiteDataStore::fetchDataAndApply(WTF::OptionSet<WebKit::WebsiteDataType>, WTF::OptionSet<WebKit::WebsiteDataFetchOption>, WTF::Ref<WTF::WorkQueue, WTF::RawPtrTraits<WTF::WorkQueue> >&&, WTF::Function<void (WTF::Vector<WebKit::WebsiteDataRecord, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>)>&&) 0x00000001b5ac659c (WebKit + 0x006ab59c) WebKit::WebsiteDataStore::fetchData(WTF::OptionSet<WebKit::WebsiteDataType>, WTF::OptionSet<WebKit::WebsiteDataFetchOption>, WTF::Function<void (WTF::Vector<WebKit::WebsiteDataRecord, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>)>&&) 0x00000001b542c7a8 (WebKit + 0x000117a8) -[WKWebsiteDataStore(WKPrivate) _fetchDataRecordsOfTypes:withOptions:completionHandler:] 0x0000000100f256b8 (Chrome - wk_web_view_configuration_provider.mm: 164) web::WKWebViewConfigurationProvider::ResetWithWebViewConfiguration(WKWebViewConfiguration*) 0x0000000100f25b68 (Chrome - wk_web_view_configuration_provider.mm: 174) web::WKWebViewConfigurationProvider::GetWebViewConfiguration()
Could you please elaborate on why this is a WebKit issue? _fetchDataRecordsOfTypes:withOptions:completionHandler: is of course async and could be implemented on a secondary thread, but I'm not sure if realpath being pathologically slow is normal, and something for WebKit to be defensive against.
(In reply to Alexey Proskuryakov from comment #1) > Could you please elaborate on why this is a WebKit issue? > _fetchDataRecordsOfTypes:withOptions:completionHandler: is of course async > and could be implemented on a secondary thread, but I'm not sure if realpath > being pathologically slow is normal, and something for WebKit to be > defensive against. The main thread is hanging inside a call made by WebKit, and this is something that would be hard for an embedder to work around, given that a variety of filesystem-related calls on other threads seem to cause realpath to hang. In other words, it's not clear what else a caller of -[WKWebsiteDataStore fetchDataRecordsOfTypes:completionHandler:] can do to defend against this, since this is (afaict) required to be called on the main thread.
It does indeed seem like something that needs to be fixed in iOS, however probably below WebKit. While we can certainly import this to Radar and route internally, it would be better for you to file your own report, so that Apple engineers could ask follow-up questions.
(In reply to Alexey Proskuryakov from comment #3) > It does indeed seem like something that needs to be fixed in iOS, however > probably below WebKit. > > While we can certainly import this to Radar and route internally, it would > be better for you to file your own report, so that Apple engineers could ask > follow-up questions. Thanks, I've filed FB10448449.
Thank you!