|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #74563 curl_exec() throws internal error in curl_error()
Submitted: 2017-05-09 13:58 UTC Modified: 2017-05-12 14:19 UTC
From: jeremys at ha dot com Assigned:
Status: Not a bug Package: cURL related
PHP Version: 7.1.4 OS: RHEL 7.3
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: jeremys at ha dot com
New email:
PHP Version: OS:


 [2017-05-09 13:58 UTC] jeremys at ha dot com
Executing curl_exec() with a host/URL that refuses the connection makes curl_exec() sometimes raise an E_WARNING because curl_exec() calls curl_error() internally. The error is as follows:

curl_error() expects parameter 1 to be resource, boolean given

As you can see in the sample script, there is no explicit call to curl_error(), yet the above error is seen.

I've only been able to reproduce via Apache, not via cli.

Apache/2.4.6 (Red Hat Enterprise Linux)
PHP 7.1.3 (part of Zend Server 9.1) - I assume 7.1.4 as well since there are no relevant changes to the curl interface in the PHP source code
libcurl 7.29.0

Test script:

ini_set( 'display_errors', 1 );
ini_set( 'error_reporting', E_ALL );

set_error_handler( function ( ...$error ) {
    array_pop( $error );
    print_r( $error );

$resource = curl_init();
curl_setopt( $resource, CURLOPT_URL, '' );
curl_setopt( $resource, CURLOPT_RETURNTRANSFER, 1 );

curl_exec( $resource );
echo 'Script finished.';

Expected result:
Script finished.

Actual result:
    [0] => 2
    [1] => curl_error() expects parameter 1 to be resource, boolean given
    [2] => /usr/local/apache/htdocs2/curl-error-test.php
    [3] => 16


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2017-05-09 15:04 UTC]
Do you have Suhosin or any other security module enabled?
 [2017-05-09 15:16 UTC]
In fact - please can you just double check that you are seeing the error from the code you have listed here.

I strongly suspect you have OPCache running and the error you are seeing is from code that has been cached in memory, rather than running the latest version of that file.
 [2017-05-09 15:32 UTC] jeremys at ha dot com
No Suhosin or other security modules are running/enabled. Do you need a particular part of the php.ini?

I disabled opcache for the script by adding the following line to the top of the script:
ini_set( 'opcache.enable', 0 );

And the error still occasionally happens.
 [2017-05-09 21:59 UTC]
> I disabled opcache for the script by adding the following line to the top of the script: ini_set( 'opcache.enable', 0 );

If the script is being cached, then editing the script won't make a difference.

Please try editing what is being printed out in the error handler, to confirm the exact code you're reporting is causing the error.

The reason I'm so sceptical about what code is making that error appear, is that the error message is one that is shown when userland code calls an internal function, but is very unlikely to appear due to how curl works internally.
 [2017-05-10 13:01 UTC] jeremys at ha dot com
I appreciate your skepticism as I was quite skeptical such an error could occur, too, but alas..

With the opcache.enable directive still set to 0, I changed the die in the anonymous error handler function to print 'Error occurred.', and still received the following output (note the different line number and additional string printed at the end):

    [0] => 2
    [1] => curl_error() expects parameter 1 to be resource, boolean given
    [2] => /usr/local/apache/htdocs2/common/curl-error-test.php
    [3] => 18
Error occurred.
 [2017-05-10 22:52 UTC]
Ok, so it's impossible, but it's happening....

Two suggestions of how to investigate this further:

i) Attach a debugger like gdb to the process, set a breakpoint in  zif_curl_error (which is the C symbol name for the PHP curl_error function), and print the backtrace...this should reveal how the code even reaches there.

ii) Report this to RogueWave or whoever supports you're seeing it as part of a non-standard distribution, and it's theoretically impossible in stock PHP, someone who has access to that will need to investigate it.
 [2017-05-11 15:19 UTC] jeremys at ha dot com
Attached gdb and got a backtrace when the breakpoint was hit. From what I can tell, it's most likely a Zend issue so I'll pursue the problem with them. Thanks.

For reference, the backtrace is as follows:

Breakpoint 1, 0x00007fa4f0e6a430 in zif_curl_error () from /usr/local/zend/lib/php_extensions/
(gdb) bt
#0  0x00007fa4f0e6a430 in zif_curl_error () from /usr/local/zend/lib/php_extensions/
#1  0x00007fa4f4bfcb87 in zend_call_function () from /usr/local/zend/lib/apache2/
#2  0x00007fa4f4bfcde5 in _call_user_function_ex () from /usr/local/zend/lib/apache2/
#3  0x00007fa4e4e1c293 in ?? () from /usr/local/zend/lib/monitor/php-7.1.x/
#4  0x00007fa4e4e1ce60 in ?? () from /usr/local/zend/lib/monitor/php-7.1.x/
#5  0x00007fa4e4e28d9f in ?? () from /usr/local/zend/lib/monitor/php-7.1.x/
#6  0x00007fa4e4e1af4f in ?? () from /usr/local/zend/lib/monitor/php-7.1.x/
#7  0x00007fa4f4cbf2cc in ?? () from /usr/local/zend/lib/apache2/
#8  0x00007fa4f4c578cb in execute_ex () from /usr/local/zend/lib/apache2/
#9  0x00007fa4e57b7a9c in ZAppsPluginManager::execute(_zend_execute_data*) () from /usr/local/zend/lib/statistics/php-7.1.x/
#10 0x00007fa4e4e1b6a1 in ?? () from /usr/local/zend/lib/monitor/php-7.1.x/
#11 0x00007fa4f4cc18d4 in zend_execute () from /usr/local/zend/lib/apache2/
#12 0x00007fa4f4c0ca70 in zend_execute_scripts () from /usr/local/zend/lib/apache2/
#13 0x00007fa4f4ba13b0 in php_execute_script () from /usr/local/zend/lib/apache2/
#14 0x00007fa4f4cc41e2 in ?? () from /usr/local/zend/lib/apache2/
#15 0x00007fa4fdfd0690 in ap_run_handler ()
#16 0x00007fa4fdfd0bd9 in ap_invoke_handler ()
#17 0x00007fa4fdfe500a in ap_process_async_request ()
#18 0x00007fa4fdfe52e4 in ap_process_request ()
#19 0x00007fa4fdfe1c32 in ap_process_http_connection ()
#20 0x00007fa4fdfd9c90 in ap_run_process_connection ()
#21 0x00007fa4f847c80f in child_main () from /etc/httpd/modules/
#22 0x00007fa4f847ca55 in make_child () from /etc/httpd/modules/
#23 0x00007fa4f847cab6 in startup_children () from /etc/httpd/modules/
#24 0x00007fa4f847d7c0 in prefork_run () from /etc/httpd/modules/
#25 0x00007fa4fdfb4f6e in ap_run_mpm ()
#26 0x00007fa4fdfadd76 in main ()
 [2017-05-12 14:19 UTC]
-Status: Open +Status: Not a bug
 [2017-05-12 14:19 UTC]
Closing as Not a Bug as curl_error() is definitely called from within the ZendMonitor extension, something we cannot do anything about.
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Wed Apr 14 04:01:24 2021 UTC