|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #59749 APC breaks file includes/requires in wordpress
Submitted: 2011-05-04 19:12 UTC Modified: 2011-06-06 22:26 UTC
From: brett at brettbrewer dot com Assigned:
Status: Closed Package: APC (PECL)
PHP Version: 5.3.5 OS: CentOS5 - 2.6.18-238.9.1.el5 #1
Private report: No CVE-ID: None
 [2011-05-04 19:12 UTC] brett at brettbrewer dot com
I'm not quite sure if this belongs here as I can't provide source code or backtraces to help diagnose this, but it seems like an APC bug to me. I was running APC 3.1.7 on a new server and was having probs with those "Unable to allocate memory for pool" error messages all over my sites. I read the changelog for apc 3.1.8 and it looked like maybe those errorss were suppressed in the latest version, so I tried running "pecl update apc" and it failed to install due to missing C compiler in my path. I then updated using "yum update php-pecl-apc" via the remi repos where the rest of my php install came from and it worked. I then restarted apache and checked my wordpress sites and they load fine on the first request, but then on subsequent requests various include files included via "require" cause warnings and fatal errors such as:
Warning: require(twitter.php): failed to open stream: No such file or directory in on line 411 Warning: require(twitter.php): failed to open stream: No such file or directory in require(twitter.php): failed to open stream: No such file or directory on line 411 Fatal error: require(): Failed opening required 'twitter.php' (include_path='.:/usr/share/pear:/usr/share/php') in � ��* on line 411 

I did some brief testing on my non-wordpress sites and didn't see this error on my sites built in Kohana, but I'm not 100% sure this is specific to Wordpress or not. I can't tell if this is only an issue with Wordpress plugins or if all require statements are triggering this. I have ensured that my wordpress installs and all plugins are updated to the latest versions just to be sure that wasn't the prob. I do not have any special wordpress caching plugins turned on either as I know there have been some conflicts with APC and supercache or some other wp cache plugins in the past. I'm not a linux expert or an internals programmer (obviously), so that's about the best info I can provide. Anyone else seen this problem?

I have no example code to provide other than the current Wordpress codebase, but here are some specs for my OS, Apache, PHP and APC configuration:

OS: CentOS5 - x64
Linux Kernel Version: 2.6.18-238.9.1.el5
Apache Version: 	Apache/2.2.3 (CentOS)
Apache API Version: 	20051115  
Loaded Modules: 	core prefork http_core mod_so mod_auth_basic mod_auth_digest mod_authn_file mod_authn_alias mod_authn_anon mod_authn_dbm mod_authn_default mod_authz_host mod_authz_user mod_authz_owner mod_authz_groupfile mod_authz_dbm mod_authz_default util_ldap mod_authnz_ldap mod_include mod_log_config mod_logio mod_env mod_ext_filter mod_mime_magic mod_expires mod_deflate mod_headers mod_usertrack mod_setenvif mod_mime mod_dav mod_status mod_autoindex mod_info mod_dav_fs mod_vhost_alias mod_negotiation mod_dir mod_actions mod_speling mod_userdir mod_alias mod_rewrite mod_proxy mod_proxy_balancer mod_proxy_ftp mod_proxy_http mod_proxy_connect mod_cache mod_suexec mod_disk_cache mod_file_cache mod_mem_cache mod_cgi mod_version mod_php5 mod_proxy_ajp mod_ssl 

PHP Version: 5.3.6 - installed from remi repos via yum.

PHP configure command from phpinfo(): 
'./configure' '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-libdir=lib64' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' '--disable-rpath' '--without-pear' '--with-bz2' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' '--enable-gd-native-ttf' '--with-t1lib=/usr' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-zlib' '--with-layout=GNU' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--with-kerberos' '--enable-ucd-snmp-hack' '--enable-shmop' '--enable-calendar' '--with-libxml-dir=/usr' '--enable-xml' '--with-system-tzdata' '--with-mhash' '--with-apxs2=/usr/sbin/apxs' '--without-mysql' '--without-gd' '--disable-dom' '--disable-dba' '--without-unixODBC' '--disable-pdo' '--disable-xmlreader' '--disable-xmlwriter' '--without-sqlite' '--without-sqlite3' '--disable-phar' '--disable-fileinfo' '--disable-json' '--without-pspell' '--disable-wddx' '--without-curl' '--disable-posix' '--disable-sysvmsg' '--disable-sysvshm' '--disable-sysvsem' 

Server API 	Apache 2.0 Handler
Virtual Directory Support 	disabled
Configuration File (php.ini) Path 	/etc
Loaded Configuration File 	/etc/php.ini
Scan this dir for additional .ini files 	/etc/php.d
Additional .ini files parsed 	/etc/php.d/20ioncube.ini, /etc/php.d/apc.ini, /etc/php.d/curl.ini, /etc/php.d/dba.ini, /etc/php.d/dom.ini, /etc/php.d/fileinfo.ini, /etc/php.d/gd.ini, /etc/php.d/imap.ini, /etc/php.d/json.ini, /etc/php.d/ldap.ini, /etc/php.d/mbstring.ini, /etc/php.d/mcrypt.ini, /etc/php.d/memcache.ini, /etc/php.d/mysql.ini, /etc/php.d/mysqli.ini, /etc/php.d/pdo.ini, /etc/php.d/pdo_mysql.ini, /etc/php.d/pdo_sqlite.ini, /etc/php.d/phar.ini, /etc/php.d/pspell.ini, /etc/php.d/soap.ini, /etc/php.d/sqlite.ini, /etc/php.d/wddx.ini, /etc/php.d/xmlreader.ini, /etc/php.d/xmlwriter.ini, /etc/php.d/xsl.ini, /etc/php.d/zip.ini
PHP API 	20090626
PHP Extension 	20090626
Zend Extension 	220090626
Zend Extension Build 	API220090626,NTS
PHP Extension Build 	API20090626,NTS
Debug Build 	no
Thread Safety 	disabled
Zend Memory Manager 	enabled
Zend Multibyte Support 	disabled
IPv6 Support 	enabled
Registered PHP Streams 	https, ftps, compress.zlib, compress.bzip2, php, file, glob, data, http, ftp, phar, zip
Registered Stream Socket Transports 	tcp, udp, unix, udg, ssl, sslv3, sslv2, tls
Registered Stream Filters 	zlib.*, bzip2.*, convert.iconv.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk, mcrypt.*, mdecrypt.* 

Non-standard PHP extensions I'm running:
ionCube PHP Loader v4.0.8 - the one you know and probably don't love
DBG v3.9.10 - the debug extension for my ide

APC Runtime config settings:
APC Support	disabled (for now)
Version 	3.1.8
APC Debugging 	Disabled
MMAP Support 	Enabled
MMAP File Mask 	/dev/zero
Locking type 	pthread mutex Locks
Serialization Support 	broken
Revision 	$Revision: 308812 $
Build Date 	May 4 2011 16:07:55

Directive	Local Value	Master Value
apc.cache_by_default	On	On
apc.canonicalize	Off	Off
apc.coredump_unmap	Off	Off
apc.enable_cli	Off	Off
apc.enabled	Off	Off
apc.file_md5	Off	Off
apc.file_update_protection	2	2
apc.filters	no value	no value
apc.gc_ttl	3600	3600
apc.include_once_override	Off	Off
apc.lazy_classes	Off	Off
apc.lazy_functions	Off	Off
apc.max_file_size	1M	1M
apc.mmap_file_mask	/dev/zero	/dev/zero
apc.num_files_hint	0	0
apc.preload_path	no value	no value
apc.report_autofilter	Off	Off
apc.rfc1867	Off	Off
apc.rfc1867_freq	0	0
apc.rfc1867_prefix	upload_	upload_
apc.rfc1867_ttl	3600	3600
apc.serializer	default	default
apc.shm_segments	1	1
apc.shm_size	64M	64M
apc.slam_defense	On	On
apc.stat	On	On
apc.stat_ctime	Off	Off
apc.ttl	7200	7200
apc.use_request_time	On	On
apc.user_entries_hint	0	0
apc.user_ttl	7200	7200
apc.write_lock	On	On

I have tweaked most of the apc runtime settings to no avail. My dedicated server support team of linux experts has also had no luck in explaining this as anything other than an APC bug. Let me know if I can provide any further info. 


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2011-05-05 03:16 UTC]
Couple of other people have reported similar issues.

I'm treating it as a regression and if I can confirm, there'll be a patch release immediately.
 [2011-05-05 06:05 UTC] brett at brettbrewer dot com
Thanks so much for the reply. Much appreciated. I did some further testing and this really seems like it is specific to my wordpress sites -- nothing else seems to break when I enable APC. I'll keep my eyes open for any updates on this and please don't hesitate to request any further info I can provide to help diagnose. I'd even be happy to provide temporary access to the affected server if it would help. Just hit me up directly at my email address. 
 [2011-05-05 08:33 UTC] vnsavage at gmail dot com
My test case is:

cat index.php 
<?php include_once("a/include1.php"); ?>
cat a/include1.php 
<?php include_once('include2.php'); ?>
cat a/include2.php
<?php echo "Whateva"; ?>

The first refresh loads fine, the second fails with:

Warning: include_once(include2.php) [function.include-once]: 
failed to open stream: No such file or directory in 
&#65533;z&#65533; on 
line 2

This looks to be related to the:

op_array->filename = filename;

in my_compile_file(), which is used on compiled files.
From GDB:

(gdb) p executor_globals.active_op_array.filename
$39 = 0xeb77f0 "Hz?"

If this is something you want to fix, I'd be glad to help 
with more debug/patches.
 [2011-05-05 09:16 UTC] vnsavage at gmail dot com
One more problem. The test case:

apc.stat = 0

cat index.php 
<?php include_once("a/test.php"); ?>

cat a/test.php
<?php include_once('b/include1.php'); ?>

cat a/b/include1.php 
<?php include_once('include2.php'); ?>

cat a/include2.php 
<?php echo "Wrong file"; ?>

cat a/b/include2.php 
<?php echo "Correct file"; ?>

On the first execution, I get "Correct file". On the second 
execution and after I get "Wrong file".

It looks to be related to the fact that apc_copy_op_array() 
calls apc_search_paths(), which uses 
zend_get_executed_filename(), which for this test case 
returns the path to test.php, and the canonization of the 
path to include2.php gets incorrectly set to 
.../a/include2.php instead of .../a/b/include.php.

Again if this is something that you think should be fixed, 
I'd be glad to help with more debug and patches.
 [2011-05-05 09:34 UTC] pierre dot php at gmail dot com
with apc.stat=0 the problem is actually not one. It is done so 
by design. Do not use stat=0 unless you have only absolute 
paths for your include and/or no conflict in your naming.

Does it happen when using apc.stat=1?
 [2011-05-05 09:50 UTC] vnsavage at gmail dot com
Nope. With apc.stat = 1, the code path which is supposed to 
canonize the paths is not executed, so it doesn't not happen.
 [2011-05-05 15:22 UTC] brett at brettbrewer dot com
It happens with apc.stat = On in my apc.ini file. That was one of many things I tried tweaking to no avail. I started off with all default settings on APC and didn't mess with anything other than apc.shm_size until I ran into this problem. Thanks again for looking into this, I'd love to see a patch to fix it. I'm holding off on migrating a rather high profile site to a new server until I can get this sorted out. Thanks again for your help.
 [2011-05-05 18:41 UTC] vnsavage at gmail dot com
@brett - you are getting errors with apc.stat = 1, because of 
the first problem I reported.
 [2011-05-07 05:53 UTC] pokemon260 at gmail dot com
I was running Arch Linux / PHP 5.3.6 / PHP-APC 3.1.7 with no 
problem at all.

But yesterday I updated my system with pacman, and php-apc was 
updated to 3.1.8. Now I have the same issue. The relative path 
in require/include was messed with strange unicode characters.

What I had to do is downgrade to 3.1.7. Hope there's a new 
release soon.
 [2011-05-07 06:16 UTC] pierre dot php at gmail dot com
I'm not sure if that's the case here but there is a regression  
between 3.1.5/6/8 and 8, with apc.stat=0. It was done because 
of the perf impact it was causing and enabling stat again 
solved the problem.

Gopal? What do you think?
 [2011-05-07 14:34 UTC] brett at brettbrewer dot com
@pajoye/@vnsavage  - I appreciate your time on this, but I don't know if you're saying there's no problem or if I'm just misunderstanding what you're saying, but enabling stat does NOT solve the problem for me. It may solve the problem in your test cases, but it doesn't solve the problem on our wordpress sites. I see no change in APC's behavior with stat = On or stat = Off. I had to downgrade to version 3.1.6 before I could get things working right. Please clarify if this is being treated as a bug and being fixed or not. If there's any useful info I can provide about our server setup that I haven't already provided, please let me know.
 [2011-05-08 21:59 UTC] jaredsmith at jaredsmith dot net
I'm seeing a similar problem when using the php-pecl-apc-3.1.8-1.el5 package from the Remi repository.  It's breaking certain parts of Drupal (many of the ubercart modules in particular).  

Symptoms are the same: PHP complaining that it can't find a file required by the require_once function, and putting gibberish in the filename.  

Downgrading back to php-pecl-apc-3.1.7-1.el5 got things working again for me.
 [2011-05-09 04:24 UTC]
The weirdest part of this bug is that I haven't changed anything in the file-lookup algorithm between 3.1.7 and 3.1.8
 [2011-05-09 10:46 UTC]
@vnsavage: yup, you're right ... it's the free() order for h->filename that's messing this up.

Will put out a patch release tomorrow.
 [2011-05-10 08:57 UTC] vnsavage at gmail dot com
If I remember correctly, in addition to the free() order, the 
other problem with it was that it is not always the full path, 
so when it is after that used in apc_search_paths(), can't 
properly search in the zend_get_executed_filename() path 
 [2011-05-10 17:06 UTC] aruna at comunicamos dot eu
Hi Gopal, wondering whether a patch for this issue has been 
rolled yet. Exact same issue on an Ubuntu 10.4 using Drupal 6.

Warm regards, Aruna
 [2011-05-11 05:25 UTC] mikie dot simpson at gmail dot com
We have the same problem on updating from 3.1.6 to either 3.1.7 or 3.1.8 using pecl on CentOS 5.6 with php 5.3.
Setting apc.stat = 1 makes no difference and breaks Joomla and Doctrine scripts with many require_once errors and the "failed to open stream" errors.
We had to downgrade to 3.1.6 to get sites back working again.
Similar enviroment to Brett including zend and ioncube but with php53 from CentOS
 [2011-05-12 08:10 UTC] soulmob at gmail dot com
I can also confirm that we get the same error with 3.1.8. It 
has nothing to do specifically with wordpress/joomla but in 
general requiring (require_once/require/include/include_once) 
files without explicitly specifying the path. 

Although the include_path contains current directory (.) it 
cannot locate the file.

I've rolled back on 3.1.6
 [2011-05-12 14:40 UTC]
Back after being out sick.

I still can't figure out a simple enough test-case that breaks this in apc.stat=1 mode.

Anyone have any sort of test-case?

The 3.1.6 -> 3.1.7 breakage was intentional for apc.stat=0, 
the nostat mode was generating 4-5x more stats than stat=0
code, instead of erroring out. Any non-prefixed path will
error out.
 [2011-05-13 03:17 UTC] vnsavage at gmail dot com
@gopalv did you try the 2 tests I posted, running mod_php or 
 [2011-05-13 09:07 UTC]
Alright, I've been testing with apache2+mod_php.

If people can confirm that this is a 3.1.7->3.1.8 
regression, I can start going through the patches and do a 
read-through review.

Also getting a new nginx+fcgi test setup soon.
 [2011-05-13 09:37 UTC]
Nope, it's still working for me. Even after I removed '.' from include_path, on apache2.

I even have phar enabled, which also fails to break it.

Can someone give me a tarball of code which breaks with apc.stat=1, their include_path and the list of extensions/patches installed?

I'm out of options and mostly out of time, on how to make APC break.
 [2011-05-13 15:21 UTC] jens at bierkandt dot org

here is my testcase, as requested as tarball. You can find it here:

apc.stat is on

I can reproduce it this way:
- restart apache
- call apc_test/test_dir1/a.php in a browser. Result is "success"
- reload within browser. Result is: 
Warning: require_once(c.php): failed to open stream: No such file or directory in |.??e/schtorch/public_html/apc_test/test_dir2/b.php on line 2 Fatal error: require_once(): Failed opening required 'c.php' (include_path='.:/usr/share/php5:/usr/share/php5/PEAR') in |.??e/schtorch/public_html/apc_test/test_dir2/b.php on line 2

Compile log and settings are inside the archive.

Let me know if I can help further.

 [2011-05-13 15:41 UTC]
Exact same code works just fine in my apc-3.1.8 + php 5.3.4 install.

I tried a non-debug build & a zts build.

I do wonder if the include_once_override is screwing up the op_array. Can you check if it dies when that's disabled?

Once I get a valid breaking scenario I want to bisect the patches between 3.1.7 and 3.1.8 to see if I can find out exactly which commit broke it.
 [2011-05-13 16:00 UTC]
Got a new ubuntu 32bit VM up for this, with the patched php that it ships.

That seems to break with your tarball - thanks for the test-case.

(ugh, APC not being my day-job is not fun - there's goes a Friday night)
 [2011-05-13 16:33 UTC]
Mea culpa on this one.

Please check out svn trunk and test this again, please.

I think I messed up the release package.
 [2011-05-13 17:32 UTC] jens at bierkandt dot org
# pecl uninstall apc
# svn co apc (Checked out revision 310999)

Compiled (followed INSTALL file from trunk), APC version states: 3.1.8 

This is working with the test case I provided above! Does it also work for the owner of the bug?

Thanks a lot, hope you still have time for Friday night ;-)
 [2011-05-13 17:41 UTC] brett at brettbrewer dot com
I am a little hesitant to try the patch on our server now that we've got 3.1.6 running smoothly on our production server where I was having the problems. I'll have to ask our server company to install it, but I'd rather wait until a few more people have verified that this fixes their probs. If really need me to test it I will though, since I want to be as helpful as I can in resolving this. I don't want to hold up any resolution of the problem. Thanks very much for taking the time to work on it!
 [2011-05-14 01:46 UTC] barry at automattic dot com

Looks indeed like 

op_array->filename = filename;

is not in SVN (trunk or tag) but only in the release 
package.  Using either trunk or the 3.1.8 tag seems to work 
fine on all 20 million of our WordPress sites :)

Where did that line come from?  I guess package creation is 
not done from the SVN tag?
 [2011-05-14 04:49 UTC]
Yeah, that's me making a release on a sick day out of my build directory. Missed out on running an "svn revert" from testing out this patch

The reason it took me so long to find was that I never even imagined such a mistake. 

Sorry about that.
 [2011-05-14 05:54 UTC] fedora at famillecollet dot com
At first look, I think only "open_basedir" configuration are affected. But I also encountered this bug with phpMyAdmin (in 3.4.0, try to generate "charts" from serve status page).

I confirm that the fix is ok.

Do you plan te released a fixed version soon ?
(else I will push 3.1.8+patch in official fedora repository)
 [2011-06-06 22:26 UTC] brett at brettbrewer dot com
The new 3.1.9 release seems to have fixed the problem. We updated our production server today and so far so good. Thanks to everyone who helped track this down and fix it.
 [2011-08-25 11:01 UTC] james at radweb dot co dot uk
Ive been having the same issue with moving some wordpress 
sites to my new server running APC 3.1.8.

im trying to update my APC to 3.1.9 but when i run the 
command PECL install apc it returns saying

"pecl/apc is already installed and is the same as the 
released version 3.1.9, install failed"

if i check my apc version on my apc.php it says im running 
3.1.8 and there is an upgrade available.

anyone got any ideas how i can upgrade my APC?
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Jun 17 11:01:31 2024 UTC