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: No Feedback
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:
Here is an example script that shows one way:
### a.php ###
function test_function()
{
}
### b.php ###
class Test_Class
{
public static function runTest() {}
}
### main.php ###
require_once('./a.php'); // first ./ require seems to always be included
require_once('./b.php'); // eventually might not be included
test_function();
Test_Class::runTest();
echo 'complete';
####
EXPECT: 'complete'
ACTUAL: mostly 'complete'. Eventually, maybe Fatal error: class 'Test_Class' not
found.
Some more information:
I cannot provide a test script that always reproduces the issue because the behavior is
inconsistent. The issue seems related to the Zend Opcache, since I no longer experienced the issue
when opcache was disabled for about 24 hours. However, perhaps I just didn't test vigorously
enough.
*Sometimes* ./ requires will simply be overlooked, as if the require line is not present in the
script at all. Restarting php-fpm fixes the issue for a while.
I have had this occur in different PHP scripts for different requires and the result is the same.
Once it happens in one script, it will continue happening in the same script until php-fpm is
restarted. The curious part, if this was related to Zend Opcache, is that even if the script is
modified e.g. to check get_included_files(), the modified version of the script will still exhibit
the same behavior (I'm not familiar with how Zend Opcache works -- perhaps it updates using
deltas?)
I have not yet tried with opcache.use_cwd=0
Perhaps it is related to this config variable being turned on.
I have done some searching on this behavior, and I came across this: http://stackoverflow.com/questions/8490667/php-class-not-found-but-its-included
Although the difference is that I am using ./, the end result is similar (PHP class not found even
though it's included).
Perhaps PHP is internally converting ./ to http://localhost/ on some
occasions, although I do not know why it would. But this would give the result that I am
experiencing. Just some ideas.
Previous Comments:
------------------------------------------------------------------------
[2015-03-22 04:22:18] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
------------------------------------------------------------------------
[2015-03-21 13:43:32] pegasus at vaultwiki dot org
My mistake, this still occurs in the installation after running the script a few times. It seems
this has something to do with the Zend Opcache. When it is disabled, I can no longer reproduce the
issue.
------------------------------------------------------------------------
[2015-03-21 13:28:00] pegasus at vaultwiki dot org
This issue was fixed by re-installing the affected PHP installation.
------------------------------------------------------------------------
[2015-03-09 17:04:28] pegasus at vaultwiki dot org
Strange. Re-did make install, restarted php-fpm, and this issue has magically disappeared.
------------------------------------------------------------------------
[2015-03-08 05:01:26] rasmus@php.net
I am not able to reproduce this. Can you provide a standalone example?
Looking at both the code and an strace, nothing has changed here. An explicit require of
./includes/filename.php will only attempt to load that file from the directory the parent script is
in.
------------------------------------------------------------------------
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