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_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.

Maybe this is relevant !?

commit 1b8ed4ad2318765665fef636a3d66b89fa4d8da6
Author: Daniel Stenberg <daniel_at_haxx.se>
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

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