Magic constants (__DIR__) problem

[Peter Thomassen]

Hi,

I am running Ubuntu 12.04 with PHP 5.5.9 and XCache 3.1.0.

Two of my virtual hosts have Joomla installations which use __DIR__ in a require() statement in libraries/composer_autoload.php, line 22. The users userA and userB associated with the virtual hosts cannot reach each other's files. The files are in

/home/userA/http/libraries/ClassLoader.php

/home/userB/http/libraries/ClassLoader.php

I am now getting the following error when accessing userA's site:

Warning: require(/home/userB/http/libraries/ClassLoader.php): failed to open stream: Permission denied in /home/userA/http/libraries/composer_autoload.php on line 22

Fatal error: require(): Failed opening required '/home/userB/http/libraries/ClassLoader.php' (include_path='.:/usr/share/php:/usr/share/pear') in /home/userA/http/composer_autoload.php on line 22

I suppose this is because userB's site was accessed before, so that __DIR__/ClassLoader.php turned into /home/userB/http/libraries/ClassLoader.php, which was then stored in the cache. Since userA's composter_autoload.php file is identical to userB's, it will try to require() userB's file.

Is my suspicion correct? Can I do anything against this (e.g. simple fix, or bug report instead)?

In the XCache Changelog, I saw that a __DIR__ and __FILE__ bug was fixed in 3.1.0. This seems to be a different problem, though, since I'm already using 3.1.0.

Your help is greatly appreciated!

Thanks,

Peter

[Carsten Schmitz]

Hello,

I am having the same problem. Because of this I have two Joomla installlations trying to load files from each others paths (which are protected by open_base_dir) and fail so I get blank pages.
This is clearly a bug in Xcache as there are no problems after Xcache  is deactivated/disabled

Any help or workaround would be much appreciated (using the same version of PHP & XCache here)

[Carsten Schmitz]

I solved the problem by removing Xcache.
Why? Because PHP 5.5 already included opcode caching by using Zend OPcache. Most probably stuff was cached twice.
I have not tried to remove opcache in favor of xcache.

[Xuefer]

Thanks for the report. I'm wondering if you can reproduce this issue immediately after php is restarted, or can't reproduce it until running it for a while

If it is immediately not random issue I believe we can have it fixed. Just need the php code simplified yet still reproduced

--

---
You received this message because you are subscribed to the Google Groups "XCache" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xcache+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Yui Bei Fong]

Carsten, you can use only one opcode cache, if your php.ini has opcache.so loaded, then you shouldnt use opcode caching in Xcache
however, you can load both extensions and use partial functionality, i.e. just variable cache in xcache, its tested and works well

OpCache has no isolation or "path smashing" protection, if you use chroot's , script paths can be the same and therefore things can go messed up.
Suggestion for XCache - use namespaces, xcache.var_namespace =        "USER" or "SERVER_NAME"

[No Spam please]

I use XCache 3.1.0 still on 5.2.17 VC6 and it seems this bug has been introduced in 3.2.0 ?!
http://xcache.lighttpd.net/ticket/352#ticket

I hope anyone is able to build latest versions with VC6 sometimes. Thanks