-
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
Run into EXC_BAD_ACCESS crash occasionally at curl_multi_cleanup() when DOH enabled since 8.5.0. #14207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
name lookup
DNS and related tech
Comments
Here is the callstack of one crash with curl v8.8.0. Thread 1 Queue : com.apple.main-thread (serial)
#0 0x000000010003fd10 in multi_done at curl/curl/lib/multi.c:699
#1 0x000000010003f576 in curl_multi_cleanup at curl/curl/lib/multi.c:2891
#2 0x000000010000abcc in Client::~Client() at curl-test/src/main.cpp:202
#3 0x000000010000aba5 in Client::~Client() at curl-test/src/main.cpp:201
#4 0x000000010000ab5b in std::__1::default_delete<Client>::operator()[abi:v160006](Client*) const at /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/usr/include/c++/v1/__memory/unique_ptr.h:65
#5 0x000000010000aadc in std::__1::unique_ptr<Client, std::__1::default_delete<Client>>::reset[abi:v160006](Client*) at /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/usr/include/c++/v1/__memory/unique_ptr.h:297
#6 0x000000010000aa79 in std::__1::unique_ptr<Client, std::__1::default_delete<Client>>::~unique_ptr[abi:v160006]() at /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/usr/include/c++/v1/__memory/unique_ptr.h:263
#7 0x0000000100003275 in std::__1::unique_ptr<Client, std::__1::default_delete<Client>>::~unique_ptr[abi:v160006]() at /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/usr/include/c++/v1/__memory/unique_ptr.h:263
#8 0x0000000100002e5a in main at curl-test/src/main.cpp:332
#9 0x00007ff80268d386 in start () |
icing
added a commit
to icing/curl
that referenced
this issue
Jul 17, 2024
When removing an easy handle that had DoH sub-easy handles going, those were not removed from the multi handle. Their memory was reclaimed on curl_easy_cleanup() of the owning handle, but multi still had them in their list. Add `Curl_doh_close()` and `Curl_doh_cleanup()` as common point for handling the DoH resource management. Use the `multi` present in the doh handles (if so), for removal, as the `data->multi` might already have been NULLed at this time. - refs curl#14207
Closed
Thanks for the detailed report and the sample program. That made reproducing the issue easy. I have #14212 as a fix for this, making the sample program run without hickups. Hope this works for you too. |
@icing Thank you very much. The patch works well. |
bagder
pushed a commit
that referenced
this issue
Jul 18, 2024
When removing an easy handle that had DoH sub-easy handles going, those were not removed from the multi handle. Their memory was reclaimed on curl_easy_cleanup() of the owning handle, but multi still had them in their list. Add `Curl_doh_close()` and `Curl_doh_cleanup()` as common point for handling the DoH resource management. Use the `multi` present in the doh handles (if so), for removal, as the `data->multi` might already have been NULLed at this time. Reported-by: 罗朝辉 Fixes #14207 Closes #14212
meslubi2021
pushed a commit
to Unity-Curl/curl
that referenced
this issue
Jul 19, 2024
When removing an easy handle that had DoH sub-easy handles going, those were not removed from the multi handle. Their memory was reclaimed on curl_easy_cleanup() of the owning handle, but multi still had them in their list. Add `Curl_doh_close()` and `Curl_doh_cleanup()` as common point for handling the DoH resource management. Use the `multi` present in the doh handles (if so), for removal, as the `data->multi` might already have been NULLed at this time. Reported-by: 罗朝辉 Fixes curl#14207 Closes curl#14212
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I did this
Dependency versions:
Below is a complete C++ test program for this case.
The specific version reproduction situation is as follows:
v8.3.0, v8.4.0, v8.5.0, v8.6.0, v8.7.0, v8.8.0
If the enable_DoH in the code is set to false, it will not crash.
v8.3.0, v8.4.0
If the enable_DoH in the code is set to true, it will not crash.
v8.5.0, v8.6.0, v8.7.0, v8.8.0
If the enable_DoH in the code is set to true, it will crash.
I expected the following
No EXC_BAD_ACCESS crash.
curl/libcurl version
Tested the following versions:
curl 8.3.0-DEV (x86_64-apple-darwin23.3.0) libcurl/8.3.0-DEV SecureTransport zlib/1.3.1 c-ares/1.19.0
Release-Date: [unreleased]
Protocols: dict file ftp ftps http https
Features: AsynchDNS HSTS HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL threadsafe UnixSockets
curl 8.4.0 (x86_64-apple-darwin23.3.0) libcurl/8.4.0 SecureTransport zlib/1.3.1 c-ares/1.19.0
Release-Date: 2023-10-11
Protocols: dict file ftp ftps http https
Features: AsynchDNS HSTS HTTPS-proxy IPv6 Largefile libz NTLM SSL threadsafe UnixSockets
curl 8.5.0 (x86_64-apple-darwin23.3.0) libcurl/8.5.0 SecureTransport zlib/1.3.1 c-ares/1.19.0
Release-Date: 2023-12-06
Protocols: dict file ftp ftps http https
Features: AsynchDNS HSTS HTTPS-proxy IPv6 Largefile libz NTLM SSL threadsafe UnixSockets
curl 8.6.0 (x86_64-apple-darwin23.3.0) libcurl/8.6.0 SecureTransport zlib/1.3.1 c-ares/1.19.0
Release-Date: 2024-01-31
Protocols: dict file ftp ftps http https ipfs ipns
Features: AsynchDNS HSTS HTTPS-proxy IPv6 Largefile libz NTLM SSL threadsafe UnixSockets
operating system
MacOS 14.3
This issue occurs on Windows 10 and Ubuntu 1804 too.
The text was updated successfully, but these errors were encountered: