Do you use apc.stat=1 or 0?

Both apc.stat=0 and apc.stat=1 fail. This is not a duplicate 
of the other issue.

This makes APC useless for Drupal (< 7), and I guess for many 
other web frameworks.

Can you try with 3.1.6 please or even better a svn version?

I should have clarified that this behavior is present in 3.1.6 
(which is very sad for the first stable release in years).

I tried with trunk, which also has that behavior. Reverting 
r305003 on top of trunk fixes caching of relative files.

ok, thanks for the tests!

Will see why it passes through our tests :P

Gopal, why did we do that by default? I thought the idea was to actually kill relative path and include_path support for apc.stat=0, not for stat=1. That's obviously a bad break, even if using relative path and include path is indeed a bad idea from a perf point of view.

The issue really is this assumption I made.

"./x.php" is really dirname(__FILE__)."/x.php"

I can see that it isn't the case, which is weird.

Because in php 5.3 svn, I have the exact same test working.

To make sure we're on the same page for this

gopalv@delta:/opt/php53/var/www$ find 20529/

20529/
20529/index.php
20529/a
20529/a/include2.php
20529/a/include1.php


gopalv@delta:/opt/php53/var/www$ cat 20529/index.php 
<?php

include_once("./a/include1.php");
?>

gopalv@delta:/opt/php53/var/www$ cat 20529/a/include1.php 
<?php

include_once("./a/include2.php");
?>

gopalv@delta:/opt/php53/var/www$ cat 20529/a/include2.php 
<?php
$a = apc_cache_info();
print_r($a["cache_list"]);
print_r(get_include_path());

Now, when I run this

Array
(
    [0] => Array
        (
            [type] => file
..
            [filename] => /opt/php53/var/www/20529/index.php
        )

    [1] => Array
        (
            ...
            [filename] => /opt/php53/var/www/20529/a/include1.php
        )

    [2] => Array
        (
            [filename] => /opt/php53/var/www/20529/a/include2.php
        )

)

/opt/php53/usr/share/php:/opt/php53/lib/php

From all I can tell, it is working exactly as it should.

I might be a little out-of-focus today, so if I did something bad up there, please point it out.

Actually, I can confirm that it actually works on PHP 5.3.

I suppose that on PHP 5.3, APC doesn't call 
apc_search_paths() at all 
(maybe rely on sapi_get_stat()?).

I confirmed that it indeed fails on PHP 5.2.

The logic of apc_search_paths() is definitely wrong anyway, 
because 
"./x.php" is really getcwd()."/x.php", not 
dirname(__FILE__)."/x.php".

I see how this slipped through my tests.

For include_once(), php resolves the full path before it gets to APC. The same would fail with include("./a/include2.php");

I'll fix this. Thanks for the test case.

And the -stable marker is really for the new allocator implementation than anything else. 

And please do post benchmarks against 3.0.19 vs 3.1.x, for your use case.

Here you go

http://news.php.net/php.pecl.cvs/15081

Please check up on this.

Thanks damien and gopalv for this fix.

My Drupal install was also suffering this and it has been a 
pain to debug.