Bug #79382 [Com]: Fatal error: Cannot redeclare getallheaders() in ...

Edit report at https://bugs.php.net/bug.php?id=79382&edit=1 ID: 79382 Comment by: admin at franceserv dot fr Reported by: admin at franceserv dot fr Summary: Fatal error: Cannot redeclare getallheaders() in ... Status: Open Type: Bug Package: *General Issues Operating System: Linux PHP Version: 7.3.15 Block user comment: N Private report: N New Comment: Yes exactly, the file is this one : https://github.com/ralouphie/getallheaders/blob/develop/src/getallheaders.php The condition "if (!function_exists('getallheaders'))" isn't checked and I need (same for few people over Internet too) rename the function "function getallheaders()" to "function _something_different_here_getallheaders()" to avoid the problem ... A friend is using PHP 7.4 and he don't have this problem, but I don't know where to look because a configuration which change behavior of the function "function_exists()" is very strange. Previous Comments: ------------------------------------------------------------------------ [2020-03-14 10:31:56] cmb@php.net Among others, this is about <https://github.com/ralouphie/getallheaders/blob/develop/src/getallheaders.php>. ------------------------------------------------------------------------ [2020-03-14 08:48:50] nikic@php.net I doubt this is opcache related. PHP 7.3 added getallheaders() for the FPM SAPI and the code also tries to define this function. You mention that there is a function_exists check, which should have prevented this. Can you share what the file that containts the getallheaders() declaration looks like? ------------------------------------------------------------------------ [2020-03-14 03:45:38] admin at franceserv dot fr You have right, this problem is strange because I don't find it into bugs.php.net after so much long time. Thank you about the idea to check opcache, I disabled it temporary for testing but the problem was still here ... I will continue to check my configuration but it don't seem to be related with opcache ... if someone have an idea and solved this problem on his configuration it's interest me ... ------------------------------------------------------------------------ [2020-03-14 02:49:54] daverandom@php.net Reading through the docs for the opcache ini settings[1] I note that the default value for opcache.optimization_level was changed in 7.3 to remove a flag, and a brief wander through the source reveals that the flag in question acquired new meaning between 7.2 and 7.3[2], and is also described as "unsafe", as is one of its neighbours that was removed from the default in 5.6.18. Hypothetically speaking, if one were to set up a new PHP installation by, say, copy-pasting the same ini files that originate in ancient history and have been passed from version to version since PHP 5, and hypothetically they maybe had buggered about with opcache related settings at some point and "turned everything on to make it faster", then hypothetically they might end up in a situation where those unsafe flags are set. Hypothetically. I could be way off base there, but whatever is going on this has opcache fingerprints all over it. The fact that you are consistently seeing the same issue across many point releases in two minor version branches indicates that this is a config/environment issue. As such, the best place to start would be to conduct a thorough review of the active PHP configuration (i.e. phpinfo()), paying particularly close attention to opcache. I feel like this is stating the obvious, but if were the case that multiple large scale foss projects had been fundamentally incompatible with new releases of PHP for the last 14+ months, someone would probably have noticed before now. [1] https://www.php.net/manual/en/opcache.configuration.php [2] https://github.com/php/php-src/commit/a02a126d54077d1f2f3c9a54a00a7e75d5b8f562#diff-18518eac33b6061b9da5d72d4637417a ------------------------------------------------------------------------ [2020-03-13 23:35:41] bugreports at gmail dot com developers simply need to learn that it's a terrible idea to taint the global namespace with random *unprefixed* userland functions eveniif the function_exists() hack would work what makes you thinking that your handcrafted function is signature and *behavior" compatible? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=79382 -- Edit this bug report at https://bugs.php.net/bug.php?id=79382&edit=1