> On 12 Oct 2018, at 20:02, Ray Satiro via curl-library <curl-library_at_cool.haxx.se> 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 (https://github.com/curl/curl/blob/432eb5f5c254ee8383b2522ce597c9219877923e/lib/multi.c#L2133,
>> 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->extmsg.data.result’.
>>
>> 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
> https://github.com/curl/curl/commit/acefdd0 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 (https://github.com/curl/curl/commit/151d3c56d) passes the test, whereas the commit in question (https://github.com/curl/curl/commit/acefdd0) 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.

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