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: Mon, 26 Oct 2020 23:04:24 +0000
On 26/10/2020 22:09, Daniel Stenberg wrote:
> On Mon, 26 Oct 2020, Tomalak Geret'kal via curl-library
> wrote:
>
>> On closer examination, sigpipe_ignore is a no-op unless
>> USE_OPENSSL or USE_MBEDTLS are set.
>
> Are you saying you're not using any of them?
>
>> So it seems the call in curl_easy_perform is only really
>> intended to eat up pipes raised by either of those
>> libraries, thus perhaps they don't really make sense on a
>> "raw" byte-reading function.
>
> Those are the only places that can trigger SIGPIPE, me
> knowingly! All uses of the sockets by libcurl itself
> should already be protected.
>
I got it from curl_easy_recv. I believe the triggering
condition was iOS nuking the underlying socket while the app
was suspended.
Based on the `#if defined`s in sigpipe.h, from what I can
tell, curl doesn't protect anything from SIGPIPE unless
OpenSSL or MBEDTLS are in use. I don't know whether your
intention was to protect against SIGPIPE more broadly or not.
Admittedly my build is using a "non-standard" config-ios.h,
but the result is USE_SECTRANSP which I believe is supported
and also available for use by Mac builds. Unless I'm missing
something, this condition would also cause a SIGPIPE on a
Mac, for example... though I'm not sure how you'd ever
trigger it on that particular platform.
N.B. after I just chucked a "signal(SIGPIPE, SIG_IGN)" call
at the top of my program and called it a day, I found that
"dead" socketry also impacted the wakeup socket pair as
managed by curl_multi_poll - see issue #6132 for more on
that. :)
Cheers
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2020-10-27
Date: Mon, 26 Oct 2020 23:04:24 +0000
On 26/10/2020 22:09, Daniel Stenberg wrote:
> On Mon, 26 Oct 2020, Tomalak Geret'kal via curl-library
> wrote:
>
>> On closer examination, sigpipe_ignore is a no-op unless
>> USE_OPENSSL or USE_MBEDTLS are set.
>
> Are you saying you're not using any of them?
>
>> So it seems the call in curl_easy_perform is only really
>> intended to eat up pipes raised by either of those
>> libraries, thus perhaps they don't really make sense on a
>> "raw" byte-reading function.
>
> Those are the only places that can trigger SIGPIPE, me
> knowingly! All uses of the sockets by libcurl itself
> should already be protected.
>
I got it from curl_easy_recv. I believe the triggering
condition was iOS nuking the underlying socket while the app
was suspended.
Based on the `#if defined`s in sigpipe.h, from what I can
tell, curl doesn't protect anything from SIGPIPE unless
OpenSSL or MBEDTLS are in use. I don't know whether your
intention was to protect against SIGPIPE more broadly or not.
Admittedly my build is using a "non-standard" config-ios.h,
but the result is USE_SECTRANSP which I believe is supported
and also available for use by Mac builds. Unless I'm missing
something, this condition would also cause a SIGPIPE on a
Mac, for example... though I'm not sure how you'd ever
trigger it on that particular platform.
N.B. after I just chucked a "signal(SIGPIPE, SIG_IGN)" call
at the top of my program and called it a day, I found that
"dead" socketry also impacted the wakeup socket pair as
managed by curl_multi_poll - see issue #6132 for more on
that. :)
Cheers
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2020-10-27