Can you please post a small reproduce class that always triggers this problem?

Do you have any code which includes the same class multiple times with include?

like

if(...) {
 class foo {};
}

If you do, then that breaks under high load.

http://notmysock.org/blog/php/inclusion-checks

read.

I am encountering this problem in the context of the Wordpress Supercache 
plugin:
http://wordpress.org/support/topic/supercache-internal-zend-error-wtf
http://mytech.dsa.me/en/2011/08/09/apc-include_once_override-problem-
solve/#comments

PHP version 5.3.1, APC version 3.1.9, OS RHEL 5

The code in that file (wp-content/plugins/wp-super-cache/wp-cache-base.php) is 
as follows:
if (!class_exists('CacheMeta')) {
        class CacheMeta { //PHP FATAL ERROR APPEARS WITH THIS LINE REFERENCE
                var $dynamic = false;
                var $headers = array();
                var $uri = '';
                var $post = 0;
        }
}

See also bug 58618. It is suggested there that this problem appears after the 
cache is filled and cleaned up. Indeed, these problems started appearing only 
after we reduced the size of the APC cache, and only after the server runs for a 
while.

I had these bug with PHP 5.3.13 on Debian 6.

Same error : PHP Fatal error:  Internal Zend error - Missing class 
information for  in /foo/bar.php on line X

The file contains 4 class with for each a class_exists() check before.

The server run APC. And the problem appear on an ecommerce website 2 times in about 2 months (on the online payment script...).

Same Error happend.


* Error message
---
PHP Fatal error:  Internal Zend error - Missing class information for  in 
/foobar/xoops_trust_path/wizin/src/Wizin_Util.class.php on line 24
---


* Code:
Xoops Cube Legacy 2.1.7 + wiz moble HD 0.43


---
if (! class_exists('Wizin_Util')) {
    require dirname(__FILE__) . '/Wizin.class.php';

    /**
     * Wizin framework utility class                                                
     *                                                                              
     * @access public                                                               
     *                                                                              
     */
    class Wizin_Util
    {
        /**
         * return string for something salt
         *
         * @param string $salt                                                      
         * @return string $prefix                                                   
         */ 
        function
---

line 23,24 are
---
    class Wizin_Util
    {
---


* The way I fixed this problem

Delete the white space between ! and class_exists


* Enviroment 

CentOS 6.3

* PHP version
PHP 5.3.16 (cli) (built: Aug 16 2012 13:52:03) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
    with Suhosin v0.9.29, Copyright (c) 2007, by SektionEins GmbH

I ran across this related to wp-super-cache as well. I then ran across this 
solution: 
http://wordpress.org/support/topic/plugin-wp-super-cache-error-zend-on-gandi-
hosting

APC seems to dislike patterns that match the file name.

In my case the problem is related to restarts of Apache.
That is to say that the pb occur after an apache restart and need an other restart of apache to disapear.
In fact, this problem has been described in 2005 (php4) here : http://grokbase.com/t/php/pecl-dev/05aecvj5pt/apc-internal-zend-error-on-class-definition
8 years later, still the same bug.

My solution has been to disable APC.

This may not be fixable. As Gopal mentioned in this bug, this is probably 
happening because the same class is defined both dynamically and non-
dynamically. By that I mean, if you have:

if(condition) {
   class Foo {
      ...
   }
}

and at the same time you have a top-level class Foo {} definition in another 
file. It would depend which file is hit first after a server restart on whether 
or not you see this error. The only reliable solution is not to write code like 
that. It really isn't a good idea to have the same class defined in multiple 
places anyway.

Scenario that recreates this message / bug:

Implement a spl_autoload_register() function and in class files requiring a 
parent class 
(dependencies). This occured for me after upgrading from PHP 4 to PHP 5.3 and 
implementing 
autoload. Example:

<?php
    require "dependency/parent_class.php";
    if (!class_exists("child_class", false)) {
        class child_class extends parent_class {
            // stuff
        }
    }

In another file, implement the spl_autoload_register function and make it call 
the class.