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: curl_easy_recv and SIGPIPE
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Tomalak Geret'kal via curl-library <curl-library_at_cool.haxx.se>
Date: Tue, 27 Oct 2020 14:22:19 +0000
On 27/10/2020 12:33, Daniel Stenberg wrote:
> On Tue, 27 Oct 2020, Tomalak Geret'kal via curl-library
> wrote:
>
>>> What did you see? From where is the SIGPIPE and was
>>> SO_NOSIGPIPE set on that socket?
>>>
>> I've said already: from the recv call in curl_easy_recv.
>>
>> And yes it was.
>
> Curious - in two parts.
>
> 1. SIGPIPE is typically generated when tring to send data
> on a socket without a reader, not when reading.
>
> But since you speak of "the recv call in curl_easy_recv"
> and there is no "recv" call in that function, I assume you
> refer to the Curl_read() call? That can in itself end up
> writing to the socket if that's what the TLS library
> wants. Sound reasonable?
Indeed.
I wasn't aware that the conn->recv call in Curl_read() (as
invoked by curl_easy_recv) can be more than just a ::recv.
This all makes some more sense now.
>
> 2. SO_NOSIGPIPE is documented in Apple's own iOS
> documentation[*] as:
>
> SO_NOSIGPIPE is an option that prevents SIGPIPE from
> being raised when a
> write fails on a socket to which there is no reader;
> instead, the write
> to the socket returns with the error EPIPE when there is
> no reader.
>
> ... so if SO_NOSIGPIPE truly was set on that socket, this
> sounds like Apple's bug?
>
> [*] =
> https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/getsockopt.2.html
>
Yes, I think it's an Apple bug that the signal is raised
here in the first place (as I hypothesised at the start!).
For what it's worth, I can confirm that SO_NOSIGPIPE remains
nominally set on the socket for the duration.
I don't think there's anything to do here in libcurl, beyond
confirming (or denying!) that sigpipe_ignore is /supposed/
to be a no-op if neither OpenSSL or Mbed TLS is in use, a
fact I discovered while looking into this other issue.
Cheers
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2020-10-27
Date: Tue, 27 Oct 2020 14:22:19 +0000
On 27/10/2020 12:33, Daniel Stenberg wrote:
> On Tue, 27 Oct 2020, Tomalak Geret'kal via curl-library
> wrote:
>
>>> What did you see? From where is the SIGPIPE and was
>>> SO_NOSIGPIPE set on that socket?
>>>
>> I've said already: from the recv call in curl_easy_recv.
>>
>> And yes it was.
>
> Curious - in two parts.
>
> 1. SIGPIPE is typically generated when tring to send data
> on a socket without a reader, not when reading.
>
> But since you speak of "the recv call in curl_easy_recv"
> and there is no "recv" call in that function, I assume you
> refer to the Curl_read() call? That can in itself end up
> writing to the socket if that's what the TLS library
> wants. Sound reasonable?
Indeed.
I wasn't aware that the conn->recv call in Curl_read() (as
invoked by curl_easy_recv) can be more than just a ::recv.
This all makes some more sense now.
>
> 2. SO_NOSIGPIPE is documented in Apple's own iOS
> documentation[*] as:
>
> SO_NOSIGPIPE is an option that prevents SIGPIPE from
> being raised when a
> write fails on a socket to which there is no reader;
> instead, the write
> to the socket returns with the error EPIPE when there is
> no reader.
>
> ... so if SO_NOSIGPIPE truly was set on that socket, this
> sounds like Apple's bug?
>
> [*] =
> https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/getsockopt.2.html
>
Yes, I think it's an Apple bug that the signal is raised
here in the first place (as I hypothesised at the start!).
For what it's worth, I can confirm that SO_NOSIGPIPE remains
nominally set on the socket for the duration.
I don't think there's anything to do here in libcurl, beyond
confirming (or denying!) that sigpipe_ignore is /supposed/
to be a no-op if neither OpenSSL or Mbed TLS is in use, a
fact I discovered while looking into this other issue.
Cheers
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2020-10-27