Yes in your case it calls getaddrinfo which is blocking in a separate thread, however it waits in multi_done for the resolve to complete:

git blame puts it at ac9a179

When the application just started the transfer and then stops it while
the name resolve in the background thread hasn't completed, we need to
wait for the resolve to complete and then cleanup data accordingly.

Enabled test 1553 again and added test 1590 to also check when the host
name resolves successfully.

Detected by OSS-fuzz.
Closes #1968

I think we should just let it leak

This isn't easy.

Leaking is a problem for tools that trigger on this (like OSS-Fuzz did) and for applications who'd do this several times. I don't think we can allow that to happen unconditionally. But also not responding sooner to this sort of failure is also disturbing...

If the thread can be abandoned with ownership of all its resources which it later cleans up itself (I'm assuming here) then I don't see what benefit there is to waiting for it other than to please OSS-Fuzz. I think the fuzzer is wrong in this case.

Perhaps we should track the number of detached threads and have Curl_resolver_global_cleanup wait for the count to drop to 0 before returning?

And smarter fix would track detached threads on per-multi-handle basis and do similar wait in curl_multi_cleanup

This would have to be rather intricate, since curl_multi_cleanup is called from multi thread as well, thus, cannot do blocking wait.

Any wait for the pending thread(s) will risk blocking a call that will effect some users. We can only really fix this issue by removing the wait completely. If the threads don't leak any memory by this, I think it can be done. We just have to keep logic to make sure the OSS-Fuzz and possibly other tests don't consider that a leak.

If the threads don't leak any memory by this, I think it can be done.

Threads leak their stacks.

This issue can't be fully fixed in libcurl, but users of libcurl (e.g. the command line curl tool) should be able to clean up by invoking exit() instead of curl_multi_cleanup(). GNU cp command does exactly this, when it isn't built for Valgrind.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

I also encountered this issue.
I'm currently building a PHP application, accessing an external API while the user requests the page. In order to not slow down the page speed in case of any problems with the API, I want to skip the api call after a certain timeout. For that I set CURLOPT_TIMEOUT_MS to 150. Unfortunately this doesn't worked reliably. Since we faced issues with the external API or better said, with the dns resolving, I often got this error: Resolving timed out after 252 milliseconds. I've no idea where the 252 ms comes from, but not that 252ms is already too much, I saw the requests in the end takes even longer. For example when the average request took 500ms, some requests took 1200ms or even 1500ms which should never happen if the timeout would be adhered.

My guess: even that were seems to be a timeout of 252ms for the dns resolving, this timeout will be ignored. This could be valid since I figured out with dig that the dns resolving some times really took 500ms or longer.

Since I put the domain in the /etc/hosts the page speed is much more stable.

I hope this story was helpful for someone!

curl 7.38.0 (x86_64-pc-linux-gnu) libcurl/7.38.0

The php script was similar to this:

<?php
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, '...');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_FAILONERROR, true)
curl_setopt($ch, CURLOPT_TIMEOUT_MS, 150);
curl_setopt($ch, CURLOPT_PROXY, null);
curl_exec($ch);
var_dump(curl_error($ch));