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.

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. 
Regards,
Brett

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.

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.

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?

Nope. With apc.stat = 1, the code path which is supposed to 
canonize the paths is not executed, so it doesn't not happen.

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.

@brett - you are getting errors with apc.stat = 1, because of 
the first problem I reported.

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.

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?

@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.

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.

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

@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.

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 
fallback.

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

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

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

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.

@gopalv did you try the 2 tests I posted, running mod_php or 
php-fpm?

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.

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.

Hi,

here is my testcase, as requested as tarball. You can find it here:
http://bierkandt.org/apc_test.tar.gz

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.

Jens

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.

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)

Mea culpa on this one.

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

I think I messed up the release package.

# pecl uninstall apc
# svn co http://svn.php.net/repository/pecl/apc/trunk 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 ;-)

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!

Hi,

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?

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

http://pecl.php.net/bugs/bug.php?id=22673

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

Sorry about that.

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)

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.

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?