Hi, 

your problem seems to be a general problem of apc when classes extends other classes and taughter classes include_once other files. A lot of boards on the net descripe this problem. Some days ago I've also searched for this sympthoms and a possible solution. I have found a hint to include the missing file a second time. 
Here http://pecl.php.net/bugs/bug.php?id=5401 is a concrete scenario. 

Let's hope this problem will be solved :-)

Thanks for the link, I'll try upgrading to CVS HEAD.

If it is the early-binding vs. late-binding problem you are hitting, CVS HEAD won't fix it.  The fix for this is extremely complicated.  We are working on it, but even when we fix it you are better off fixing your code to not switch back and forth between early and late binding on the same files.

The problem seems to be triggered with our dynamically-loaded 
modules that can inherit from other modules (mainly 
localization and layout skins). This seems to fit with the 
early/late binding thing if I understand it correctly.

I've added in a stub to preload the extra dependencies for 
those classes that need it; hopefully that'll clear this up.

http://mail.wikipedia.org/pipermail/wikitech-l/2006-January/
033660.html

Brion's change seems to have stopped the missing parent class errors, so I'll change the report title if I can, to reflect this diagnosis. The corrupted function invocations seemed to stop after we upgraded to the CVS version of APC, so we'll call that part of the report a duplicate of 5401.

Be careful here though.  If it is early vs. late binding issues, then the first request after a server restart sets the tone for the remaining requests until you either restart or change one of the files in question.

The reason being that if the first request which triggers the cache insert of a particular file is a conditional include which pushes the class definition into the executor, then the cached opcodes will include the FETCH_CLASS call and you will always be doing late binding.  This is slow, but will always work.  If, on the other hand, the first request is a non-conditional top-level include then the early binding optimization kicks in and the cached opcode array won't include the FETCH_CLASS which means that a later conditional include on that same file will then exhibit the problem.

That's what I mean about cleaning up your code to either always do early or late binding, but don't mix them on the same file.  The easiest way to do this is to always put your includes at the very top level and never use include_once/require_once.  Not only do the _once calls lead to this confusion, they are also tremendously slow under an opcode cache because of the way they are implemented with a non-opcode-cached environment in mind.

Thanks for the advice. I had noticed the slowness of require_once/include_once (see http://wikitech.leuksman.com/view/Slow_require_once ), in fact I spent some time studying the APC and PHP source to see if there was an obvious way to fix it. I saw that the REQUIRE opcode called compile_filename() instead of zend_compile_file() and mistakenly assumed it didn't pass through APC at all. Obviously it does, and it does so without opening the file, what's more. So that seems like a good way to proceed.

Would it be possible to convert an early bound class declaration to a late binding one at the time when the class is restored? Presumably the NOP is still there, could you just change it back to a FETCH_CLASS if the parent does not exist? I know it's a hack but that seems to be the name of the game. Alternatively you could change the bytecode specification to give some reasonably version-independent and stable way to switch between early and late binding.

Actually, the way I tried to fix it was to have APC maintain an inheritance tree meaning that as it loads the op_arrays it detects child classes and if the parent is missing it adds a parent->child element to an array.  Then for each new class it sees it checks to see if it is in the array as a parent and if so does the parent->child inheritance which essentially means copying methods down into the child.  Where this gets nasty is when you have multi-level inheritance where you have A->B->C and you load C, then B but since A hasn't been seen yet you can't do the b->c inheritance yet.  Might first patch for this just did a 1-level thing and actually fixed most of these, but having it half-baked like this is obviously not the way to go.  My multi-level fix still has some problems I haven't been able to figure out yet.  You can see the code for this on the branch called "INH_FIX" in CVS.  I haven't had much time lately to devote to this.

Fixed in CVS HEAD for php 5.1.x.

The classes which mix dynamic and static binding are detected and the opcodes from those files are not cached. 

Introduced apc.report_autofilter to report the auto-filtering  of such errant classes. Also the reports can be used to pinpoint classes which are runtime binding and probably can be modified to be compile-time binding for optimal performance.

Just noticed the other corruption errors. Please re-test current CVS head and confirm whether the recent race condition fixes have done anything for it.

Sounds like this one is fixed, closing....