Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Wrong Curl_timeleft result leads to connection timeout when CURLOPT_TIMEOUT_MS / CURLOPT_CONNECTTIMEOUT_MS is close to LONG_MAX #5583
I did this
I reached into this problem by trying to simulate an "infinite" timeout for the connection. Since 0 means 300 seconds, it felt natural to force it to LONG_MAX to achieve the goal of "no connection timeout"
I expected the following
The example should work since the timeout is "infinite" (aka LONG_MAX)
Latest release: libcurl/7.70.0, Release-Date: 2020-04-29
I've run the example on WSL but it can be reproduced on genuine Linux systems as well.
Linux 4.19.84-microsoft-standard #1 SMP Wed Nov 13 11:44:37 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Analysis of the problem
Well, the title of the issue it's a bit misleading because the problem isn't in Curl_timeleft itself but in its parameters. See below my analysis
While checking for the root cause of the issue, I have debugged the following relevant parts:
Why does Curl_timediff return a negative value? The short answer is: because the newer timestamp is older than the older one :). What happens is the following:
I'm not proficient enough in curl's internals to understand why the
Why is this problem only visible with
It's done to reduce the number of calls to the time function. The problem here seems to be the mix of using the previous value and a refreshed value...
@mback2k I've just checked it against the current master (aka hash
Yes, since the timestamps that mark the start of operations (i.e. progress.startop and progress.startsingle) are set within the loop of multi_runsingle, the
Setting a timeout to INT_MAX could cause an immediate error to get returned as timeout because of an overflow when different values of 'now' were used. This is primarily fixed by having Curl_pgrsTime() return the "now" when TIMER_STARTSINGLE is set so that the parent function will continue using that time. Reported-by: Ionuț-Francisc Oancea Fixes #5583