Do you have Suhosin or any other security module enabled?

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.

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.

> 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.

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):


Array
(
    [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.

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 ZendServer.....as 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.

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/curl.so
(gdb) bt
#0  0x00007fa4f0e6a430 in zif_curl_error () from /usr/local/zend/lib/php_extensions/curl.so
#1  0x00007fa4f4bfcb87 in zend_call_function () from /usr/local/zend/lib/apache2/libphp7.so
#2  0x00007fa4f4bfcde5 in _call_user_function_ex () from /usr/local/zend/lib/apache2/libphp7.so
#3  0x00007fa4e4e1c293 in ?? () from /usr/local/zend/lib/monitor/php-7.1.x/ZendMonitor.so
#4  0x00007fa4e4e1ce60 in ?? () from /usr/local/zend/lib/monitor/php-7.1.x/ZendMonitor.so
#5  0x00007fa4e4e28d9f in ?? () from /usr/local/zend/lib/monitor/php-7.1.x/ZendMonitor.so
#6  0x00007fa4e4e1af4f in ?? () from /usr/local/zend/lib/monitor/php-7.1.x/ZendMonitor.so
#7  0x00007fa4f4cbf2cc in ?? () from /usr/local/zend/lib/apache2/libphp7.so
#8  0x00007fa4f4c578cb in execute_ex () from /usr/local/zend/lib/apache2/libphp7.so
#9  0x00007fa4e57b7a9c in ZAppsPluginManager::execute(_zend_execute_data*) () from /usr/local/zend/lib/statistics/php-7.1.x/ZendStatistics.so
#10 0x00007fa4e4e1b6a1 in ?? () from /usr/local/zend/lib/monitor/php-7.1.x/ZendMonitor.so
#11 0x00007fa4f4cc18d4 in zend_execute () from /usr/local/zend/lib/apache2/libphp7.so
#12 0x00007fa4f4c0ca70 in zend_execute_scripts () from /usr/local/zend/lib/apache2/libphp7.so
#13 0x00007fa4f4ba13b0 in php_execute_script () from /usr/local/zend/lib/apache2/libphp7.so
#14 0x00007fa4f4cc41e2 in ?? () from /usr/local/zend/lib/apache2/libphp7.so
#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/mod_mpm_prefork.so
#22 0x00007fa4f847ca55 in make_child () from /etc/httpd/modules/mod_mpm_prefork.so
#23 0x00007fa4f847cab6 in startup_children () from /etc/httpd/modules/mod_mpm_prefork.so
#24 0x00007fa4f847d7c0 in prefork_run () from /etc/httpd/modules/mod_mpm_prefork.so
#25 0x00007fa4fdfb4f6e in ap_run_mpm ()
#26 0x00007fa4fdfadd76 in main ()

Closing as Not a Bug as curl_error() is definitely called from within the ZendMonitor extension, something we cannot do anything about.