Bug #78485 [NEW]: Random "couldn't resolve host" failures in curl_multi
| From: | sinus at sinpi dot net | 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