Download
Browse source Changelog tiny-curl
Documentation
Project   Bug Bounty   Help us   Known bugs   TODO Protocols   CA bundle   HTTP Cookies   HTTP/2   SSL Certs Releases   Security   Version numbers   Vulnerabilities curl tool   man page   Tutorial   HTTP scripting Who and Why
libcurl
ABI API Competitors Examples Features Mailing list Related libs Using libcurl Tutorial Testimonials
Get Help
curl-library curl-users Mailing lists Book: Everything curl Video presentations Report a bug Paid support
Development
Autobuilds Code review Code style Contribute Dashboard Deprecate Internals Release Notes Release Procedure Roadmap Run Tests Security Process Specifications Test curl
News
Changelog Release table
curl / Mailing Lists / curl-library / Single Mail
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: Failed sending data to the peer in 7.72.0

From: James Brown via curl-library <curl-library_at_cool.haxx.se>
Date: Wed, 16 Sep 2020 11:09:07 -0700

I've been running 7.72.0 with that patch cherry-picked for over a day and
the issue has not recurred. There's definitely something spooky going on.
Does extract_if_dead have any other side effects?

On Wed, Sep 16, 2020 at 1:22 AM Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Mon, 14 Sep 2020, James Brown via curl-library wrote:
>
> Thanks for digging deep into this issue!
>
> > I went through commits on master that aren't in 7.72.0 and came across
> > 728f8d3bd
> > <
> https://github.com/curl/curl/commit/728f8d3bdc336e3fa838f45cad6c0133a6b604ae>,
>
> > which looks promising. It says it partially reverts a change from
> 7.65.2,
> > which is kind of weird because this problem does *not *occur for me in
> > 7.71.1, which suggests that one of the other changes in 7.72.0 (maybe
> the
> > schannel stuff?) somehow had some spooky-action-at-a-distance and made
> this
> > much worse in 7.72.0.
>
> Well, the problem this commit fixes is the opposite: libcurl would
> previously
> reuse connections that actually are already dead and thus detecting the
> "deadness" gets delayed.
>
> > I feel like 728f8d3bd still has a race condition if the FIN has been
> issued
> > by the server but not yet processed by poll, but that's neither here nor
> > there.
>
> It's a race, sure, but that shouldn't be a problem. If the connection is
> dead
> at the time extract_if_dead() is called, it should detect that and not
> reuse
> the connection.
>
> If it dies a millisecond after the check, the connection will instead be
> reused and the sending of the outgoing request will subsequently fail.
> libcurl
> will then attempt to create a new connection and retry the request over
> that.
>
> If indeed calling extract_if_dead() there causes the problem for you, then
> I'd
> like to get more information about what exactly the problem is within that
> function so that we can address that rather than just reverting the commit
> again and just go full yoyo on these issues!
>
> --
>
> / daniel.haxx.se | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://www.wolfssl.com/contact/
> 

-- 
James Brown
Engineer

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2020-09-16