curl / Mailing Lists / curl-library / Single Mail


Re: libCurl 7.61.1: no response message received indicating dead connection

From: Bernd Mueller \(bermuell\) via curl-library <>
Date: Tue, 16 Oct 2018 14:00:51 +0000

> On 12 Oct 2018, at 20:02, Ray Satiro via curl-library <> wrote:
> On 10/9/2018 9:40 AM, Bernd Mueller (bermuell) via curl-library wrote:
>> I’m reaching out to you as we saw a functional change in libCurl which might not have been intended or to get advice how to cope with it on application side.
>> When moving from libCurl version 7.61.0 to 7.61.1 a response message is not received anymore
>> in case of ‘dead connection’ (‘stream_error’ in multi.c). Where as we
>> received in 7.61.0 a response message with error code 7="Couldn't connect to server”.
>> It looks like that the reason is the introduction of the state function ‘Curl_init_completed’ for state CURLM_STATE_COMPLETED which stops all the timers by calling ‘Curl_expire_clear’.
>> In the above mentioned error case
>> * “Completed” state is the next state
>> * as a result, all timers are stopped (which was not the case in v7.61.0)
>> * response message which is created afterwards (,
>> with error code indicating the ’timed out’) is never received by the application because of the stopped timers...I assume.
>> I tried not stopping/clearing the timers in that ‘error’ situation and then we receive on application side the response message with the expected error code in ‘msg->’.
>> Is there a change required on application side to get informed about the failing attempt to send the message in that situation?
>> We’re using
>> - libCurl (7.61.1).
>> - multi interface to connect to a server using HTTPS.
> To be clear are you saying that libcurl will no longer indicate when it
> can't connect to the server? The only commit I can find that is related
> to what you are talking about is
> but I don't see how it could
> cause this issue. My understanding is libcurl should call
> Curl_expire_clear. Are you able to reproduce consistently and can you
> confirm that commit is the issue by testing it and its parent?

yes, that’s what I’m saying. At least the way how a ‘dead connection’ was indicated before the change mentioned above.
We have a test case covering this situation and the parent commit ( passes the test, whereas the commit in question ( fails. So yes it’s deterministic.

When I change the libCurl code of that commit in such a way that the “Curl_expire_clear” is not called
_only_ in the ‘dead connection’ situation, we receive the message as expected
and all our positive tests and negative tests pass.
So the Curl_expire_clear causes a change in behaviour in that specific ‘error situation’. Why, I can’t tell.
I had a quick look at the libCurl test cases but couldn’t find one which is covering this situation.

Received on 2018-10-16