Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: libcurl 8.16.0 spawning large number of getaddrinfo threads?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Demi Marie Obenour <demiobenour_at_gmail.com>
Date: Sat, 18 Oct 2025 21:05:04 -0400
On 10/17/25 04:27, Stefan Eissing via curl-library wrote:
>
>
>> Am 17.10.2025 um 01:45 schrieb Vadim Grinshpun via curl-library <curl-library_at_lists.haxx.se>:
>>
>> Hi folks,
>> I'm working on a project that makes use of libcurl.
>> After upgrading libcurl from 8.14.1 to 8.16.0, I've noticed an unexpected behavior change.
>> Specifically, I'm observing a large number of curl_thread_create_thunk threads, all of which
>> appear to have a backtrace like the one shown below.
>>
>> Since the only thing that changed is the libcurl version,
>> I want to double-check a few things:
>> - are there any known issues in 8.16.0 that might have symptoms like this?
>> - has anything changed between 8.14.1 and 8.16.1 that might lead to this behavior?
>> - is it possible to misuse libcurl in a way that can lead to this behavior?
>
> curl 8.16.0 uses pthread_cancel() to make threads terminate early when the results are no longer needed. This was reverted in de3fc1d7adb78c078e4cc7ccc48e550758094ad3, as it proved to be unreliable due to unsoundness of libc's implementations. See https://eissing.org/icing/posts/rip_pthread_cancel/ for my analysis of this.
>
> What you see in the stacktraces seem to be exactly that. libc holds a lock and does not release it on a pthread_cancel, leading to all other started resolver threads to wait on this.
>
> The workarounds are either to apply the mentioned patch or to build curl using c-ares for resolving. Or try our recent release candidate https://curl.se/rc/ for curl 8.17 due on November 5.
>
> - Stefan
Should distros build with c-ares by default? I'm wondering if
getaddrinfo() is just too poor an interface.
Received on 2025-10-19
Date: Sat, 18 Oct 2025 21:05:04 -0400
On 10/17/25 04:27, Stefan Eissing via curl-library wrote:
>
>
>> Am 17.10.2025 um 01:45 schrieb Vadim Grinshpun via curl-library <curl-library_at_lists.haxx.se>:
>>
>> Hi folks,
>> I'm working on a project that makes use of libcurl.
>> After upgrading libcurl from 8.14.1 to 8.16.0, I've noticed an unexpected behavior change.
>> Specifically, I'm observing a large number of curl_thread_create_thunk threads, all of which
>> appear to have a backtrace like the one shown below.
>>
>> Since the only thing that changed is the libcurl version,
>> I want to double-check a few things:
>> - are there any known issues in 8.16.0 that might have symptoms like this?
>> - has anything changed between 8.14.1 and 8.16.1 that might lead to this behavior?
>> - is it possible to misuse libcurl in a way that can lead to this behavior?
>
> curl 8.16.0 uses pthread_cancel() to make threads terminate early when the results are no longer needed. This was reverted in de3fc1d7adb78c078e4cc7ccc48e550758094ad3, as it proved to be unreliable due to unsoundness of libc's implementations. See https://eissing.org/icing/posts/rip_pthread_cancel/ for my analysis of this.
>
> What you see in the stacktraces seem to be exactly that. libc holds a lock and does not release it on a pthread_cancel, leading to all other started resolver threads to wait on this.
>
> The workarounds are either to apply the mentioned patch or to build curl using c-ares for resolving. Or try our recent release candidate https://curl.se/rc/ for curl 8.17 due on November 5.
>
> - Stefan
Should distros build with c-ares by default? I'm wondering if
getaddrinfo() is just too poor an interface.
-- Sincerely, Demi Marie Obenour (she/her/hers)
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-keys attachment: OpenPGP public key
- application/pgp-signature attachment: OpenPGP digital signature