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_at_entry=0x7fffcc461513,
nbytes=nbytes_at_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_at_entry=0x7fffcc3f1290,
type=type_at_entry=21,
    buf=buf_at_entry=0x7fffcc3baca8 "\001", len=len_at_entry=2) at
ssl/record/rec_layer_s3.c:915
#5 0x00007ffff6a80b8d in do_ssl3_write (s=s_at_entry=0x7fffcc3f1290,
type=type_at_entry=21, buf=0x7fffcc3baca8 "\001",
    pipelens=pipelens_at_entry=0x7fffdd0a24c4, numpipes=numpipes_at_entry=1,
    create_empty_fragment=create_empty_fragment_at_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_at_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_at_entry=0x7fffa4023730,
in_connect=in_connect_at_entry=0x7fffa4023740,
    asyncp=asyncp_at_entry=0x7fffdd0a27a6,
protocol_done=protocol_done_at_entry=0x7fffdd0a27a7) at ../../lib/url.c:4669
#15 0x00007ffff6d07a13 in multi_runsingle
(multi=multi_at_entry=0x7fffcc000b20, now=..., data=data_at_entry=0x7fffa4023730)
    at ../../lib/multi.c:1420
#16 0x00007ffff6d088d1 in curl_multi_perform (multi=0x7fffcc000b20,
    running_handles=running_handles_at_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.

Best Regards,
Sam

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html