Edit report at https://bugs.php.net/bug.php?id=69199&edit=1
ID: 69199
Comment by: pegasus at vaultwiki dot org
Reported by: pegasus at vaultwiki dot org
Summary: require_once doesn't require ./ files
Status: Re-Opened
Type: Bug
Package: Scripting Engine problem
Operating System: Centos 6 64-bit
PHP Version: master-Git-2015-03-07 (Git)
Block user comment: N
Private report: N
New Comment:
Confirmed on the latest build that this issue is only reproducible with the following ini:
opcache.use_cwd=1
The issue does not occur with:
opcache.use_cwd=0
Previous Comments:
------------------------------------------------------------------------
[2015-03-27 07:05:18] rasmus@php.net
Still unable to reproduce. I followed your steps exactly. My pass #1 and pass #3 outputs are
identical. Current PHP 7 build running php-fpm under nginx on Debian8.
------------------------------------------------------------------------
[2015-03-26 13:14:05] pegasus at vaultwiki dot org
As a follow-up, I have discovered that once this error occurs, the PHP output is used for every PHP
script in the future.
e.g. we made the error occur in main.php
But if we have another script main2.php that has completely different code and output, the previous
incorrect output of main.php is used. This explains why all the sites on my server go down together
when this error occurs on just one of them (even sites using different FPM pools).
------------------------------------------------------------------------
[2015-03-26 13:07:09] pegasus at vaultwiki dot org
Following the logic of my previous post, I am now able to consistently reproduce this bug in a very
simple script with all files in the same local directory (no sub-directories, no symlinked
directories, and none of the parent directories are symlinked anywhere as far as I know):
#### 1.php ####
require_once('./2.php');
function test1()
{
echo 'never used';
}
#### 2.php ####
function test2()
{
echo 'SUCCESS';
}
#### main.php ####
require_once('./1.php');
number_format('string');
test2();
exit;
#### main.php attempt #1 EXPECT & ACTUAL ####
Warning: number_format() expects parameter 1 to be float, string given in main.php on line X
SUCCESS
####
After receiving the correct actual proceed to place an "exit;" after the line that throws
an error. Run main.php again.
#### main.php attempt #2 EXPECT & ACTUAL ####
Warning: number_format() expects parameter 1 to be float, string given in main.php on line X
####
After receiving this correct actual proceed to remove the previously added "exit;" and run
main.php again. EXPECT: same result as pass #1
#### main.php attempt #3 ACTUAL ####
Warning: number_format() expects parameter 1 to be float, string given in main.php on line X
Fatal error: Call to undefined function test2() in main.php on line Y
###
Hope this helps. Basically in practice I am thinking this means that any time our real code goes
through a custom error or exception handler, future calls to the second ./ include from that process
will be ignored. This gives me some ideas where to start looking to workaround this issue while you
are figuring out the root cause.
------------------------------------------------------------------------
[2015-03-24 14:27:11] pegasus at vaultwiki dot org
This might be a red herring, but while looking in the error logs, I've noticed this for the
past few days:
1. An error of any level (e.g. E_WARNING) is raised in a script or one of its includes.
2. On the next request to the same script, the chance of Fatal error: class [already_included] not
found is increased via the same include.
I should also note, that in some cases the [class_not_found] is not being found in a context where
the class had to have been loaded and partly executed in order to reach that point:
[22-Mar-2015 21:36:21 America/Chicago] PHP Warning: Invalid argument supplied for foreach() in
/[path]/upload/vault/core/controller/ui/cart/vw.php on line 471
[22-Mar-2015 21:37:08 America/Chicago] PHP Fatal error: Class 'vw_Hard_Core' not found in
/[path]/upload/vault/core/controller/ui/cart/vw.php on line 12
Note above a warning occurs in controller/ui/cart/vw.php
Seemingly on the next request, controller/ui/cart/vw.php can't find 'vw_Hard_Core'.
However, this defies logic: controller/ui/cart is actually instantiated by the vw_Hard_Core class
earlier in the same script, so in this case it has been loaded and is known to be working as
expected -- yet it is not available in the scope of an include that recently encountered an error.
------------------------------------------------------------------------
[2015-03-23 19:04:27] pegasus at vaultwiki dot org
The only thing that stands out to me is that ./b.php has more frequently referred to a file like
./path/through/symlink/that/points/to/another/symlink/b.php
In my setup,
symlink-A links to symlink-B.
symlink-B links to realdir-C.
realdir-C contains b.php.
Hence, we have symlink-A/b.php
My main script uses require(./symlink-A/b.php');
Although I have had the issue with files in non-symlinked directories in the past. I once thought it
was related to a request occurring simultaneously as the file was locked for writing (Mercurial
push), but I have gone to bed with it working fine and woken up to a broken site due to this issue,
and I have had it happen when the only thing that changed was PHP being rebuilt (when I opened the
report that was the case). Sometimes it simply takes hours for the issue to occur.
That said, I have not noticed it happen with any non-symlinked require since Febbruary.
------------------------------------------------------------------------
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=69199
--
Edit this bug report at https://bugs.php.net/bug.php?id=69199&edit=1