Bug #78485 [NEW]: Random "couldn't resolve host" failures in curl_multi

From: Date: Mon, 02 Sep 2019 17:02:32 +0000
Subject: Bug #78485 [NEW]: Random "couldn't resolve host" failures in curl_multi
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-222526@lists.php.net to get a copy of this message
From: sinus at sinpi dot net Operating system: CloudLinux PHP version: 7.2.22 Package: HTTP related Bug Type: Bug Bug description:Random "couldn't resolve host" failures in curl_multi Description: ------------ I'm experiencing a pretty random failure of curl_multi to grab some of the handles added to it. I've already reported it to devs of libcurl, but they told me to toss this hot potato back here, as apparently curl_multi_exec is php7-curl's wrapper around libcurl's curl_multi_perform and any faults must lie in there. So, the matter at hand. I create 12 handles for http:// URLs, all using the same target machine, just different files. I add them to curl_multi. And as soon as I curl_multi_exec, randomly sometimes they all work, and sometimes only exactly first 8 get fetched, others immediately get a 6=="couldn't resolve host name" message queued in curl_multi_info_read. It's always the first handles that succeed, and the final handles that fail - n first handles work, n+1 till the end fail to resolve, with n sometimes being all 12, sometimes 8, a few times 4, but I also caught it on 11. This is in cURL 7.62 under PHP 7.2.21. Test script: --------------- $cm = curl_multi_init(); for ($i=1;i<=12;i++) { $handles[$i] = curl_init ("http://the.same.host.com/file" . $i); curl_multi_add_handle ( $cm, $handles[$i]); } $status = curl_multi_exec ($cm, $still_running); // $status gets 0, $still_running gets 8. $info = curl_multi_info_read ($cm, $queue); // $info['result']==6 "couldn't resolve host" for handle 9, $queue==3 as there are also failures queued for handles 10, 11 and 12 Expected result: ---------------- All 12 URLs retrieved, naturally. Actual result: -------------- Usually only 8 retrieved, or 12 as intended, or 4, or other numbers. It's always the last handles that fail. -- Edit bug report at https://bugs.php.net/bug.php?id=78485&edit=1 -- Fix committed: https://bugs.php.net/fix.php?id=78485&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=78485&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=78485&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=78485&r=needscript Try newer version: https://bugs.php.net/fix.php?id=78485&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=78485&r=support Expected behavior: https://bugs.php.net/fix.php?id=78485&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=78485&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=78485&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=78485&r=globals PHP version support discontinued: https://bugs.php.net/fix.php?id=78485&r=phptooold Daylight Savings: https://bugs.php.net/fix.php?id=78485&r=dst IIS Stability: https://bugs.php.net/fix.php?id=78485&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=78485&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=78485&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=78485&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=78485&r=mysqlcfg

« previous php.bugs (#222526) next »