Buy commercial curl support from WolfSSL. 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
himself.
RE: Strange very long time in curl_multi_cleanup() after an SSL request
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 21 Nov 2023 12:25:20 +0100 (CET)
On Mon, 13 Nov 2023, Frédéric BOITEUX wrote:
> My program actually blocks in the socket read. I tried to add some traces,
> but failed : I’ve tried CURL_TRC_CF() and info() tracing functions, but
> I didn’t get traces, probably because there is no more easy handle ever
> available, as my problem comes in curl_multi_cleanup(), after all
> easy_handles have been cleanup…
curl sets all its sockets in non-blocking state with curlx_nonblock(). Your
case seems to suggest that there are times when it fails to do that. What is
curious is that you are the only one seeing/reporting this. I think this fact
hints that there are additional conditions involved to trigger this.
Conditions we have not figured out yet.
> #0 __libc_recv (flags=<optimized out>, len=5, buf=0x5639c2314eb3, fd=6)
> at ../sysdeps/unix/sysv/linux/recv.c:28
> #1 __libc_recv (fd=6, buf=0x5639c2314eb3, len=5, flags=0)
> at ../sysdeps/unix/sysv/linux/recv.c:23
> #2 0x00005639c2210e12 in nw_in_read ()
If you build libcurl yourself, you could instrument the non-blocking state of
this socket, and maybe just log it just before the recv() call in
nw_in_read().
Date: Tue, 21 Nov 2023 12:25:20 +0100 (CET)
On Mon, 13 Nov 2023, Frédéric BOITEUX wrote:
> My program actually blocks in the socket read. I tried to add some traces,
> but failed : I’ve tried CURL_TRC_CF() and info() tracing functions, but
> I didn’t get traces, probably because there is no more easy handle ever
> available, as my problem comes in curl_multi_cleanup(), after all
> easy_handles have been cleanup…
curl sets all its sockets in non-blocking state with curlx_nonblock(). Your
case seems to suggest that there are times when it fails to do that. What is
curious is that you are the only one seeing/reporting this. I think this fact
hints that there are additional conditions involved to trigger this.
Conditions we have not figured out yet.
> #0 __libc_recv (flags=<optimized out>, len=5, buf=0x5639c2314eb3, fd=6)
> at ../sysdeps/unix/sysv/linux/recv.c:28
> #1 __libc_recv (fd=6, buf=0x5639c2314eb3, len=5, flags=0)
> at ../sysdeps/unix/sysv/linux/recv.c:23
> #2 0x00005639c2210e12 in nw_in_read ()
If you build libcurl yourself, you could instrument the non-blocking state of
this socket, and maybe just log it just before the recv() call in
nw_in_read().
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-11-21