On 12/19/18 4:15 PM, Samuel Hurst via curl-library wrote: > Hi All, > > > I've been having some very odd behaviour on some of my systems recently, > and it's left me very confused as to what's going on. It's not always > reproducible, but when it does happen it's after my app hasn't made a > HTTPS request to a given server for a while, and libcurl is going > through and cleaning up dead connections, it dies with SIGPIPE: > > (gdb) bt > #0 __libc_write (nbytes=31, buf=0x7fffcc461513, fd=24) at > ../sysdeps/unix/sysv/linux/write.c:27 > #1 __libc_write (fd=24, buf=buf@entry=0x7fffcc461513, > nbytes=nbytes@entry=31) > at ../sysdeps/unix/sysv/linux/write.c:25 > #2 0x00007ffff6679889 in sock_write (b=0x7fffcc3effd0, > in=0x7fffcc461513 "\025\003\003", inl=31) > at crypto/bio/bss_sock.c:111 > #3 0x00007ffff6672987 in BIO_write (b=0x7fffcc3effd0, > in=0x7fffcc461513, inl=31) at crypto/bio/bio_lib.c:232 > #4 0x00007ffff6a808f7 in ssl3_write_pending (s=s@entry=0x7fffcc3f1290, > type=type@entry=21, > buf=buf@entry=0x7fffcc3baca8 "\001", len=len@entry=2) at > ssl/record/rec_layer_s3.c:915 > #5 0x00007ffff6a80b8d in do_ssl3_write (s=s@entry=0x7fffcc3f1290, > type=type@entry=21, buf=0x7fffcc3baca8 "\001", > pipelens=pipelens@entry=0x7fffdd0a24c4, numpipes=numpipes@entry=1, > create_empty_fragment=create_empty_fragment@entry=0) at > ssl/record/rec_layer_s3.c:881 > #6 0x00007ffff6a89795 in ssl3_dispatch_alert (s=0x7fffcc3f1290) at > ssl/s3_msg.c:75 > #7 0x00007ffff6a87c75 in ssl3_shutdown (s=0x7fffcc3f1290) at > ssl/s3_lib.c:3800 > #8 0x00007ffff6a923c3 in SSL_shutdown (s=0x7fffcc3f1290) at > ssl/ssl_lib.c:1786 > #9 0x00007ffff6d34345 in ossl_close (connssl=<optimized out>) at > ../../lib/vtls/openssl.c:1196 > #10 0x00007ffff6d343b5 in Curl_ossl_close (conn=0x7fffcc1b71d0, > sockindex=<optimized out>) > at ../../lib/vtls/openssl.c:1213 > #11 0x00007ffff6cf0a6e in Curl_disconnect (conn=0x7fffcc1b71d0, > dead_connection=dead_connection@entry=true) > at ../../lib/url.c:784 > #12 0x00007ffff6cf5395 in prune_dead_connections (data=0x7fffa4023730) > at ../../lib/url.c:1022 > #13 create_conn (async=0x7fffdd0a2716, in_connect=0x7fffa4023740, > data=<optimized out>) at ../../lib/url.c:4391 > #14 Curl_connect (data=data@entry=0x7fffa4023730, > in_connect=in_connect@entry=0x7fffa4023740, > asyncp=asyncp@entry=0x7fffdd0a27a6, > protocol_done=protocol_done@entry=0x7fffdd0a27a7) at ../../lib/url.c:4669 > #15 0x00007ffff6d07a13 in multi_runsingle > (multi=multi@entry=0x7fffcc000b20, now=..., data=data@entry=0x7fffa4023730) > at ../../lib/multi.c:1420 > #16 0x00007ffff6d088d1 in curl_multi_perform (multi=0x7fffcc000b20, > running_handles=running_handles@entry=0x7fffdd0a2960) at > ../../lib/multi.c:2153 > > This is happening with a fully up-to-date version of libcurl/7.59.0 and > OpenSSL/1.1.0i from the Fedora 28 repositories. I can also reproduce it > with libcurl-master and OpenSSL 1.1.0i which I've built myself. > > I'm not setting CURLOPT_NOSIGNAL, so my understanding is that libcurl > should have a signal handler installed to catch these SIGPIPEs. In > researching this problem, I actually found a mailing list post from over > three years ago that doesn't seem to go anywhere: > https://curl.haxx.se/mail/lib-2015-04/0144.html > > Has anyone else seen this behaviour, or has any better ideas as to why > it's happening? Any thoughts of how to debug this further would also be > greatly appreciated.
Maybe this is relevant !? commit 1b8ed4ad2318765665fef636a3d66b89fa4d8da6 Author: Daniel Stenberg <[email protected]> Date: Tue Aug 21 14:52:17 2018 +0200 libcurl-thread.3: expand somewhat on the NO_SIGNAL motivation Multi-threaded applictions basically MUST set CURLOPT_NO_SIGNAL to 1L to avoid the risk of getting a SIGPIPE. Either way, a multi-threaded application that uses libcurl/openssl needs to have a signhandler for or ignore SIGPIPE on its own. Based on discussions in #2800 Closes #2904 Regards, Tim
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
