If anyone can tell me where to look for, I can give more information..

I also get this error when APC is on (Cannot access parent) in our OO code.

I'm running PHP 5.0.5 on RH ES 4 with the version of APC that pear installed Monday.

I've found that when the problem occurs, if I touch the file so it must be recached, or if I clear the cache itself, the script will then work.

So that means a possible workaround would be running a script after starting Apache that will 'touch' every file.

I hope somebody will soon get the time to look into this..

I have never tested APC with PHP 5.0.x.  Try it with PHP 5.1.x and let me know if this is still a problem there.

Touching every file after an Apache start would not help. I've found that even after touching the misbehaving file to have it work again, eventually another file will produce the same problem on the same instance of Apache.

I will look into this as soon as I can! Sadly our development machine is also a production machine, so I have to be carefull :)

Thanks for taking the time to look into this! This is a very promising package and I really feel that this should be part of the core when the bugs are fixed.

I also had similar problems when running APC with PHP 5.0.(4|5):
I use __autoload function to require_ince() files with classes.

Sometimes, when requesting a class for a parrent (i.e. when dealing with class Foo extends Bar) __autoload($className) receives the $className ALL IN LOWERCASE, e.g.:
basedbobject instead of BaseDBObject
and in the result can not find the proper file (looks for basebdobject.php instead of BaseDBObject.php).

This prevents me from using APC on my server but indeed I would like to.

Try commenting out line 1346 of apc_compile.c which has:

zend_str_tolower_copy(array[i].parent_name, elem->parent->name, strlen(elem->parent->name)+1);

I've commented out line 1517 of the 3.0.8 version of apc_compile.c, which appeared to be the equivalent line of code. The unexpected "Cannot access parent:: when current class scope has no parent" error still occurs.

I have now found a way to consistantly reproduce the error with our scripts. A page require_once()s a script which contains a child class. The file containing the parent class is required_once()d by the file containing the child class.

On the first request to the page using the child class, everything works as expected. On the second try, the error listed above occurs. I was able to prevent the error from occuring by require_once()ing the parent class before the child class in the main script for the page.

I will see if I can produce a test case when I have more time.

I've also commented out line 1517 of the 3.0.8 version of apc_compile.c and so far (after a few hours) the problem have not shown up any more - using php 5.0.5 from gentoo, apc by hand.

Was this line not necessary? I know nothing about the internal architecture of Zend2 and APC, but it works perfectly now. I think we could put it into production server if after a few days nothing wrong will happen.

If I experience any problems with this issue I will let you know.

many thanx!!!! 
michal

The bug evolved because when apc_compile.c was being fixed up,
I wasn't using zend_lookup_class for parent lookups and had
been doing EG(class_table) hash lookups which required lower
case names. Also the assumption that all classnames are case
insensitive in php and the lack of Zend2 test cases which
__autoload mixed case classes, helped in the survival of this
bug.

Now that's one out of the way :)

after a week of non-stop being online and served ~200 000 pages I did not have any problems with APC and PHP 5.0.5 after fixing the lowercase problem mentioned above.

thanx again - michal

I've now tested APC 3.0.8 with PHP 5.1.0RC1 and can confirm that "Cannot access parent:: when current class scope has no parent" still occurs erroniously. I've made a few attempts at a test case, but have been unable to make a simple case which expresses the error. 

I do know that it occurs on the second load of the page instantiating the object. The file containing the parent class is already required_once()d by another class which works correctly. Moving the require_once() from the child class' file to the file using the child class solves the problem.

changed the summary name..

This may be related to http://pecl.php.net/bugs/bug.php?id=5401.  See my note on that bug.

There appears to be a problem with the way APC handles inheritance under certain circumstances.  The bug seems to be "random" because only a particular sequence of requires and page hits will produce the problem.

jascha is correct. If I take his test case from bug #5401 and alter the files like so:

A.php
-----
<?
class A {
  function __construct() {
    print "Hello, World.<br />";
  }
}
?>

B.php
-----
<?
require_once "A.php";
class B extends A {
  function __construct() {
    parent::__construct();
  }
}
?>

second.php
----------
<?
require_once "B.php";
$obj = new B();
?>

And load first.php then second.php, the error "PHP Fatal error:  Cannot access parent:: when current class scope has no parent in B.php on line 5" occurs.

This should be fixed in CVS now.  Please grab the latest code and let me know.

I checked it, the latest CVS gives me a segfault.

I'm not sure if this error is related (I don't think so) but I'm unable to confirm if its working now.

Still having this problem with latest CVS.

PHP Fatal error:  Cannot access parent:: when current class scope has no parent in

PHP 5.1.1 on Debian stable

The previous fix for this has been reverted because it was incomplete.  If you are getting hit by this it means that your code is not being consistent about how it includes the script that defines the parent class.  You have some requests that include it from the top level unconditionally such that the class can be declared at compile-time, and then you have other requests on the same server that is trying to do a conditional include (perhaps include_once) on the file thus pushing the class definition down into the executor.  We will eventually fix this edge-case, but you really would be better off simply fixing your code and always making sure that the file containing the parent class is included unconditionally at the top level in all cases.

For optimal performance in an opcode cached environment there are a couple of simple rules to follow:

1. Never use include_once/require_once
2. Never do conditional function or class definitions
   eg. if(!function_exists('foo')) { function foo() { } }
3. Take advantage of your cache and use apc_store/fetch to
   get around per-request overhead like a config.ini

Well, I'm using vBulletin and I sort of really need APC. I can't just fix that code. I'll open a ticket though and try to investigate. I know this isn't your fault but still I think it should be fixed.

If your class structure requires conditionally loading child classes, you can work around this bug by adding the files containing the child classes to the apc.filters configuration option.

hi,

i really think this bug should be fixed asap because when you use a modularized cms with abstract classes you simply cannot avoid loading them dynamically. 

our cms *always* loads all sub-modules (classes) dynamically only when needed and so it cannot be used with apc at all. i think it's a good approach to achive speed other then including just everything on each request regardless if it'us ever used or not.

please think about it, i would really appreciate it seeing implemented :)

Dynamic loading of classes is fine as long as you consistently load them dynamically.  There is only a problem when you bounce back and forth sometimes loading the class directly and then later trying to load the same class dynamically.

I have a server that's running about 50 vBulletin sites. Modifying the PHP code isn't an option right now.

I've just switched from eaccelerator to APC as I have a site or two that requires PHP 5.x, and eacclerator throws errors at me in the 64-bit archetecture.

Any update on a fix for this?

It will take a while still.  Filter out the problematic scripts for now.

hi,

i'm still getting this error. 
i'm on php 5.1.2 with apc 3.0.8, on linux.

after "touching" the file that accesses the parent class, the error is gone.

all file inclusion happens with a autoloader, no global requires or includes. the class definition is included inside a class function of the autoloader. it uses include_once($fileName).

$fileName is pulled from a cached className -> filename lookup file.

would it be better to change the "include_once($fileName)" to 
if (!class_exists($className)) {
  include($fileName);
}

?

thanks, phil

Fix is still in the works.  It's complicated.  ;)

But once again, your best bet is to fix your code so you are not flipping back and forth between early and late binding on the same inherited classes.

hi,

thanks for the quick reply. i'm still trying to understand what would be the best i could do/fix for now, though. i think i only have conditional includes.

my whole application contains the "include_once()" function in exactly one place, inside a class that is registered to do the __autoload()-ing. so i'm pretty sure there are *only* conditional includes. (the filename to include is of course contained in a variable, read from some className => fileName mapping.)

i'd be happy to make the include unconditional, but of course i'd have to check before if the class already was defined (using class_exists, as i asked in my last comment). would that help?

if i get it right, your recommendation would be to use only unconditional include()s; and prevent that a class gets included twice by having only one include for each file?

Having the same problem on PHP 5.1.2 on FreeBSD.

I've noticed that setting 'apc.slam_defence' to, for example, 15, helps to solve the problem. But I suppose that such problem still MAY happen, thus you just achieve less probability that bug appears.

So, the intersting fact is: if all requested and included files get cached at once, bug appears. But if they get cached at different page views, all works great and bug won't appear. Could this be a solution?

How is this coming along?

I'd love to use APC (the general speed-up is great).

But it breaks Horde big time. And I'm not in the mood to start editing all horde projects.

This bug will likely increase in prevelance as more and more developers more to an object oriented approach as PHP5 gains popularity.  It's quite a bit more complicated to manage requires without the use of require_once on a complicated project with many dependencies.

I don't think it's enough to dismiss this bug by saying, "always use require instead of require_once."

Same bug on PHP 5.1.4 / Apache 2.0 / Stable APC 3.0.10 running a custom CMS. 

It seems that this bug really needs to be fixed, as a ton of people complain about it.

hi, 

my application is getting larger and larger - so it would be really cool if i could switch apc on again (see also comments above from 03/2006).

phillip

Fixed in CVS HEAD of APC for php 5.1.x .

Please turn on apc.report_autofilter if you want to know what all files are not being cached because they use mixed (runtime and compile-time) inheritance.

For the record, code with if(class_exists('xyz')){} is slower than include_once and currently APC has issues with such files being included more than once.

Any idea when the next version will be released?

Many people need this one. When is it coming? Current CVS doesn't build:

apc_main.c: In function `cached_compile':
apc_main.c:241: error: structure has no member named `autofiltered'
apc_main.c: In function `my_compile_file':
apc_main.c:320: error: structure has no member named `autofiltered'
apc_main.c:437: error: structure has no member named `autofiltered'

my bad, that's fixed now.

yay! thanks guys!