Bug 204396
| Summary: | [WinCairo][curl] Sometime becomes unable to get any network resources while browsing with WinCairoRequirements v2019.11.15 | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Fujii Hironori <fujii.hironori> |
| Component: | Platform | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | don.olmstead |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Fujii Hironori
WinCairo with WinCairoRequirements v2019.11.15.
While browsing some web sites, MiniBrowser sometime becomes unable to get any network resources.
I need to restart MiniBrowser to recover.
Callstack of curl thread of WebKitNetworkProcess.exe
> libcurl.dll!Curl_splay(curltime i, Curl_tree * t) Line 91 C
> libcurl.dll!Curl_splaygetbest(curltime i, Curl_tree * t, Curl_tree * * removed) Line 166 C
> libcurl.dll!curl_multi_perform(Curl_multi * multi, int * running_handles) Line 2253 C
> WebKit2.dll!WebCore::CurlMultiHandle::perform(int & runningHandles) Line 260 C++
> WebKit2.dll!WebCore::CurlRequestScheduler::workerThread() Line 184 C++
> WebKit2.dll!WebCore::CurlRequestScheduler::startThreadIfNeeded::__l2::<lambda>() Line 98 C++
> WebKit2.dll!WTF::Detail::CallableWrapper<void <lambda>(void),void>::call() Line 52 C++
> WTF.dll!WTF::Function<void __cdecl(void)>::operator()() Line 80 C++
> WTF.dll!WTF::Thread::entryPoint(WTF::Thread::NewThreadContext * newThreadContext) Line 149 C++
> WTF.dll!WTF::wtfThreadEntryPoint(void * data) Line 153 C++
> ucrtbase.dll!thread_start<unsigned int (__cdecl*)(void *),1>() Unknown
> kernel32.dll!BaseThreadInitThunk() Unknown
> ntdll.dll!RtlUserThreadStart() Unknown
The main thread of WebKitWebProcess.exe is just doing nothing.
> [External Code]
> WebKit2.dll!WebCore::TimerWindowWndProc(HWND__ * hWnd, unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 82 C++
> [External Code]
> WTF.dll!WTF::RunLoop::run() Line 74 C++
> WebKit2.dll!WebKit::AuxiliaryProcessMain<WebKit::WebProcess,WebKit::WebProcessMain>(int argc, char * * argv) Line 67 C++
> WebKit2.dll!WebProcessMainWin(int argc, char * * argv) Line 50 C++
> WebKitWebProcess.exe!main(int argc, char * * argv) Line 34 C++
> [External Code]
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Fujii Hironori
This issue seems to be solved by replacing with libcurl.dll of WinCairoRequirements v2019.06.17.
I see this issue various web site, but https://mainichi.jp/ is most likely happen.
FWIW, I'm using IPv6.
libcurl.dll of WinCairoRequirements v2019.11.15 is the first version of IPv6 enabled.
Fujii Hironori
I disabled IPv6 stack of my Windows PC, but the issue still happened.
Fujii Hironori
Curl sporadic splay deadlock in Windows · Issue #1360 · curl/curl
https://github.com/curl/curl/issues/1360
Inifinite loop inside libcurl curl_multi_perform · Issue #2130 · curl/curl
https://github.com/curl/curl/issues/2130
Sounds like the same with these issues. If so, this is a threading issue in WebKit side.
Fujii Hironori
I checked out curl repository, and built out today's ToT and curl-7_67_0 tag without applying any patches.
curl-7_67_0 reproduced, but ToT didn't.
It seems that this issue was solved in the master branch.
However, because I don't know the exact steps to reproduce, I'm not confident.
today's ToT:
commit 793e37767581aec7102d2ecafa34fc1316b1b31f (HEAD -> master, origin/master, origin/HEAD)
Author: Marcel Raad <Marcel.Raad@teamviewer.com>
Date: Tue Nov 26 11:31:57 2019 +0100
Command to build:
> set VCPKG_DEFAULT_TRIPLET=x64-windows-webkit
> cmake.exe .. "-DBUILD_CURL_EXE=OFF" "-DBUILD_TESTING=OFF" "-DCMAKE_USE_GSSAPI=OFF" "-DCMAKE_USE_LIBSSH2=OFF" "-DCMAKE_USE_OPENLDAP=OFF" "-DCURL_BROTLI=ON" "-DCURL_ZLIB=ON" "-DCURL_DISABLE_COOKIES=ON" "-DCURL_DISABLE_CRYPTO_AUTH=OFF" "-DCURL_DISABLE_DICT=ON" "-DCURL_DISABLE_FILE=OFF" "-DCURL_DISABLE_FTP=ON" "-DCURL_DISABLE_GOPHER=ON" "-DCURL_DISABLE_HTTP=OFF" "-DCURL_DISABLE_IMAP=ON" "-DCURL_DISABLE_LDAP=ON" "-DCURL_DISABLE_LDAPS=ON" "-DCURL_DISABLE_POP3=ON" "-DCURL_DISABLE_PROXY=OFF" "-DCURL_DISABLE_RTSP=ON" "-DCURL_DISABLE_SMTP=ON" "-DCURL_DISABLE_TELNET=ON" "-DCURL_DISABLE_TFTP=ON" "-DENABLE_ARES=OFF" "-DENABLE_MANUAL=OFF" "-DENABLE_THREADED_RESOLVER=ON" "-DUSE_NGHTTP2=ON" "-DUSE_WIN32_LDAP=OFF" "-DENABLE_IPV6=ON" "-DCURL_STATIC_CRT=0" "-DCURL_STATICLIB=0" "-DCMAKE_USE_OPENSSL=ON" "-DCMAKE_USE_WINSSL=" "-DCMAKE_MAKE_PROGRAM=C:/webkit/wcreq/g/downloads/tools/ninja/ninja-1.8.2/ninja.exe" "-DBUILD_SHARED_LIBS=ON" "-DVCPKG_CHAINLOAD_TOOLCHAIN_FILE=C:/webkit/wcreq/g/scripts/toolchains/windows.cmake" "-DVCPKG_TARGET_TRIPLET=x64-windows-webkit" "-DVCPKG_SET_CHARSET_FLAG=ON" "-DVCPKG_PLATFORM_TOOLSET=v142" "-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON" "-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON" "-DCMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY=ON" "-DCMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP=TRUE" "-DCMAKE_VERBOSE_MAKEFILE=ON" "-DVCPKG_APPLOCAL_DEPS=OFF" "-DCMAKE_TOOLCHAIN_FILE=C:/webkit/wcreq/g/scripts/buildsystems/vcpkg.cmake" "-DCMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION=ON" "-DVCPKG_CXX_FLAGS=" "-DVCPKG_CXX_FLAGS_RELEASE=" "-DVCPKG_CXX_FLAGS_DEBUG=" "-DVCPKG_C_FLAGS=" "-DVCPKG_C_FLAGS_RELEASE=" "-DVCPKG_C_FLAGS_DEBUG=" "-DVCPKG_CRT_LINKAGE=dynamic" "-DVCPKG_LINKER_FLAGS=" "-DVCPKG_TARGET_ARCHITECTURE=x64" "-DCMAKE_INSTALL_LIBDIR:STRING=lib" "-DCMAKE_INSTALL_BINDIR:STRING=bin" "-G" "Ninja" "-DCMAKE_BUILD_TYPE=Release" "-DCMAKE_INSTALL_PREFIX=C:/webkit/wcreq/g/packages/curl_x64-windows-webkit"
> cmake.exe --build .
Fujii Hironori
I'm observing this issue both in WK1 and WK2 WinCairo MiniBrowser.
Fujii Hironori
This seems the upstream bug.
remove_handle: clear expire timers after multi_done() by bagder · Pull Request #4583 · curl/curl
https://github.com/curl/curl/pull/4583
I tested by applying the patch to curl-7_67_0 tag.
Don Olmstead
(In reply to Fujii Hironori from comment #6)
> This seems the upstream bug.
>
> remove_handle: clear expire timers after multi_done() by bagder · Pull
> Request #4583 · curl/curl
> https://github.com/curl/curl/pull/4583
>
> I tested by applying the patch to curl-7_67_0 tag.
The requirements were updated with the patch today. Close if this fixes the issue.
Fujii Hironori
Thanks. It works fine.