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: flaky test 3001 in 7.74.0
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Fri, 11 Dec 2020 00:20:55 +0100 (CET)
On Thu, 10 Dec 2020, James Brown via curl-library wrote:
> This is kind of a longshot, but I've been building curl 7.74 and I notice
> that test 3001 keeps flaking on me. It always passes in isolation, but fails
> about half the time when running the whole suite. No test other than 3001
> has failed for me.
>
> Has anyone else noticed it being flaky?
I have not. I run it locally fairly frequently and it runs in the CI jobs all
the time on several platforms but I've not seen it behave oddly there either.
> I attached the output from a failed run (with a little context showing
> test3000 above passing and all subsequent tests passing); nothing in it
> jumped out at me.
>
> I would also totally believe that this is somehow an artifact of the version
> of stunnel I'm using or something else like that.
I didn't spot anything unusual either.
For those who want to skip browsing the log, the failure is visible like this
in the trace-file:
01:59:52.728862 == Info: SSL certificate verify ok.
01:59:52.745751 => Send SSL data, 5 bytes (0x5)
0000: ....k
01:59:52.750842 == Info: OpenSSL SSL_write: Connection reset by peer, errno
104
01:59:52.752324 == Info: Failed sending HTTP request
01:59:52.763461 == Info: Connection #0 to host localhost left intact
... which thus appears to be curl failing to send the HTTP request immediately
after the TLS handshake has completed.
errno 104 is ECONNRESET for "Connection reset by peer". The server reset the
connection unexpectedly.
You are using a fairly old OpenSSL version (1.0.1e is from 2013), I don't
think we can rule out that there might be a problem there, but I also can't
say for sure that there is.
Since you can't easily reproduce it stand-alone, the better way to start
getting more details might be to add fprintf() (or infof()) statements to
relevant functions. Possibly increase the log level of stunnel and see if you
can make that tell what it does to the connection and why.
Date: Fri, 11 Dec 2020 00:20:55 +0100 (CET)
On Thu, 10 Dec 2020, James Brown via curl-library wrote:
> This is kind of a longshot, but I've been building curl 7.74 and I notice
> that test 3001 keeps flaking on me. It always passes in isolation, but fails
> about half the time when running the whole suite. No test other than 3001
> has failed for me.
>
> Has anyone else noticed it being flaky?
I have not. I run it locally fairly frequently and it runs in the CI jobs all
the time on several platforms but I've not seen it behave oddly there either.
> I attached the output from a failed run (with a little context showing
> test3000 above passing and all subsequent tests passing); nothing in it
> jumped out at me.
>
> I would also totally believe that this is somehow an artifact of the version
> of stunnel I'm using or something else like that.
I didn't spot anything unusual either.
For those who want to skip browsing the log, the failure is visible like this
in the trace-file:
01:59:52.728862 == Info: SSL certificate verify ok.
01:59:52.745751 => Send SSL data, 5 bytes (0x5)
0000: ....k
01:59:52.750842 == Info: OpenSSL SSL_write: Connection reset by peer, errno
104
01:59:52.752324 == Info: Failed sending HTTP request
01:59:52.763461 == Info: Connection #0 to host localhost left intact
... which thus appears to be curl failing to send the HTTP request immediately
after the TLS handshake has completed.
errno 104 is ECONNRESET for "Connection reset by peer". The server reset the
connection unexpectedly.
You are using a fairly old OpenSSL version (1.0.1e is from 2013), I don't
think we can rule out that there might be a problem there, but I also can't
say for sure that there is.
Since you can't easily reproduce it stand-alone, the better way to start
getting more details might be to add fprintf() (or infof()) statements to
relevant functions. Possibly increase the log level of stunnel and see if you
can make that tell what it does to the connection and why.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2020-12-11