-
-
Notifications
You must be signed in to change notification settings - Fork 7k
Description
Hmm. I am experiencing some difficulties in Microsoft Git with the changes introduced by #18105, and reverting this PR "fixes" it.
The problem is that curl_multi_timeout() (when being called in a test that intentionally tries to access a non-existing server by connecting to http://127.0.0.1:5799/ when nobody is listening on that port) changed behavior. Previously, it kept returning a timeout of -1. Now, the timeout is instead first set to 200ms (or 199ms, sometimes). The next two calls return 300 seconds (i.e. not milliseconds), and the next three calls repeat that sequence, causing my test case to fail for different reasons than the expected one.
Is this by design? I could understand if the six attempts would now cause 200ms * 5 = one second of extra delay, but not an extra delay that had not been there before of more than 20 minutes.
FWIW when I tried to debug this, I saw that the 300 seconds come from the Curl_timeleft() call in the new cf_ip_ballers_run() call, which returns essentially the DEFAULT_CONNECT_TIMEOUT. The stack trace when that happens looks like this:
#0 cf_ip_ballers_run (bs=0x27752d8, cf=0x2775390, data=0x2772900, connected=0x5ff687) at cf-ip-happy.c:498
#1 0x00007ffb9c34bf1a in is_connected (cf=0x2775390, data=0x2772900, connected=0x5ff687) at cf-ip-happy.c:625
#2 0x00007ffb9c34c511 in cf_ip_happy_connect (cf=0x2775390, data=0x2772900, done=0x5ff687) at cf-ip-happy.c:758
#3 0x00007ffb9c35149a in Curl_conn_cf_connect (cf=0x2775390, data=0x2772900, done=0x5ff687) at cfilters.c:413
#4 0x00007ffb9c355c7d in cf_setup_connect (cf=0x27750a0, data=0x2772900, done=0x5ff687) at connect.c:387
#5 0x00007ffb9c3518b2 in Curl_conn_connect (data=0x2772900, sockindex=0, blocking=false, done=0x5ff687) at cfilters.c:498
#6 0x00007ffb9c397268 in multi_runsingle (multi=0xfb8410, nowp=0x5ff710, data=0x2772900) at multi.c:2429
#7 0x00007ffb9c397ccd in curl_multi_perform (m=0xfb8410, running_handles=0x5ff794) at multi.c:2758
This amount is then dutifully added to the splay list, from where curl_multi_timeout() obtains it.
I have verified that this is still an issue with the 81a9197 (GHA/linux-old: make one cmake v3.7.2 job verbose, 2025-09-28) (which was the latest revision on the master branch when I started investigating), Is this a bug, or do I now have to call cURL's API in a different way to get back the previous behavior?
Originally posted by @dscho in #18105 (comment)