|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #68698 Fatal error cannot redeclare [class not being redeclared]
Submitted: 2014-12-30 16:28 UTC Modified: 2015-02-01 04:22 UTC
Avg. Score:4.9 ± 0.3
Reproduced:7 of 7 (100.0%)
Same Version:2 (28.6%)
Same OS:0 (0.0%)
From: pegasus at vaultwiki dot org Assigned:
Status: No Feedback Package: Scripting Engine problem
PHP Version: 5.6Git-2014-12-30 (Git) OS: Centos 6 64-bit
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: pegasus at vaultwiki dot org
New email:
PHP Version: OS:


 [2014-12-30 16:28 UTC] pegasus at vaultwiki dot org
In the process of trying to debug this issue on my end:
I want to note that other bug was never resolved by the PHP team. I provided as much feedback as I could with the minimal suggestions that were made, but the bug was closed as if I never did. The change in bucket order mentioned in the report -still- results in an infinite loop in scripts using PHP master when some objects recursively call instances of themselves (it seems that a method's static variables might not be available on a second pass until the first call of the containing method that should have already created the static has completed). If someone can reopen the issue and look into it again, it would be appreciated.

Now, in the process of trying to debug that issue without any help from the PHP team, I discovered that PHP was also throwing a fatal error if the recursion was bypassed:

Fatal error: Cannot redeclare class [class_already_declared] in [file_that_doesnt_declare_that_class_at_all] on line 0

As I've noted in the message itself, the class HAS been declared already. However, the error message says that a specific file is trying to redeclare it. The file claimed does not even include the name of the class in so much as a string, and does not include any files that do either. The fact that the error gives "line 0" in the "problematic" file is also not useful information from a development standpoint.

This error is reproducible and always states that the same class is trying to re-declare from that same file. It does not matter whether opcache is disabled or enabled.

This error does NOT occur in PHP 5.6.4.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2014-12-30 17:01 UTC] pegasus at vaultwiki dot org
After looking at the classes being declared by the autoloader where this occurs, it seems that the [class_already_declared] was the last class newly instantiated before attempting to load this [file_that_declares_a_different_class].

It also appears to be the second file that uses require_once to import a specific separate abstract class, with the error-named file containing a class that extends from this abstract class.

This appears to be the first time that this situation occurs during the execution, so perhaps require_once is not working properly, and the error message is incorrectly using the name of the last instantiated class during execution, rather than the class being loaded. Even so, there is no redeclaration occurring here.

However, I was unable to recreate this scenario using a test script that imported 2 extended classes from the same abstract. The test script completes successfully, so there may be something else contributing to the problem in the background of my main script such as out-of-sync memory or hashes.
 [2015-01-09 07:26 UTC]
-Status: Open +Status: Feedback
 [2015-01-09 07:26 UTC]
We don't have enough information to investigate the problem, please provide reproducing code.
 [2015-01-14 20:04 UTC] pegasus at vaultwiki dot org
I do not get this error consistently. 90% of the time I get this bug instead:
The infinite loop caused by the bucket list change back in November. It occurs whether PHP has any active extensions or not, and only in no-debug builds.

Thus reducing this issue to a simple test script is difficult. I have only experienced this so far with one 3 MB PHP library that has a proprietary EULA, so it cannot be posted here. Similarly designed test libraries work as expected.

In a test directory, I almost had success reducing the original library to 4 files that would reproduce the fatal error. Then I made one change too many and the script executed successfully. After reversing all of the changes such that the files match the originals I am unable to reproduce the problem in my test directory.

Due to this I assumed it was limited to a specific directory structure or to a symlinked directory structure, so I tried a separate installation of the library in a different part of the server, but that infinitely looped.

I tried pointing the working test script to the original library and directory structure: the test script completes successfully; the original script still does not.

Opcache is disabled, so any caching on a directory-basis should not occur. Even so, I have to restart PHP-FPM after an infinite loop occurs because no other scripts will run, and my understanding is that restarting the process would clear the opcache.

By any chance does PHP store names of classes internally in a hashed form? If so, is it possible I may be experiencing a hash collision?

Since the issue is not consistent from one script to the next, is there some other cache other than the opcache that I might have to clear manually?
 [2015-01-18 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 [2015-01-18 04:27 UTC] pegasus at vaultwiki dot org
Still waiting for a recommendation based on my previous comment, and you closed it as if I hadn't provided feedback.
 [2015-01-18 04:55 UTC]
-Status: No Feedback +Status: Open
 [2015-01-18 05:11 UTC]
To answer your question, no there is no other cache to clear and while you have written a lot of words, you haven't actually provided anything we can go on. And since you seem to be the only person experiencing this I am not sure what to tell you. The change you pointed out as the cause of your problems doesn't look wrong in any way.
 [2015-01-18 17:49 UTC] pegasus at vaultwiki dot org
Is there a way that I can get a backtrace that will be useful to you when the fatal error occurs?
 [2015-01-19 06:25 UTC] pegasus at vaultwiki dot org
Recompiled with --enable-debug. The error does not occur with this configure option. Without this option, the error persists.

After this recent compile, I looked in the extensions directory, and I'm now a bit confused. Why is compiled as an extension even if the --enable-opcache configure option is omitted? This may have skewed previous tests as I always assumed opcache was turned off if I didn't opt to compile it.
 [2015-01-22 21:25 UTC] pegasus at vaultwiki dot org
If you need my earlier question to be more explicit:

How do you prevent PHP from compiling the Zend Opcache extension?

If I start from a fresh build directory, ./buildconf, make clean, remove the old extension directory at PREFIX/lib/php/extensions, comment out extension_dir from php.ini, and ./configure without including --enable-opcache, the final "make install" just recreates the extension directory WITH in it.

Since it was implied by rasmus in another report that my issues might be caused by an incompatible extension, I would like to completely rule out, as it's my only extension, but I can't seem to stop it from being created.
 [2015-01-23 19:54 UTC]
-Status: Open +Status: Feedback
 [2015-01-23 19:54 UTC]
--disable-opcache should do it, or alternatively, you can just not load the extension in your php.ini (since it's not built into PHP).
 [2015-02-01 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 [2015-03-21 13:28 UTC] pegasus at vaultwiki dot org
I am no longer experiencing this issue as of #d092cb6
 [2015-11-04 13:25 UTC] info at interpost dot biz
I have had this fatal error: Cannot redeclare class ... from PHP 5.6.12 through to and including 5.6.14 on Debian Jessie.  It prevents horde (webmail) admin configuration pages from loading properly (chrome gives an ERROR_EMPTY_RESPONSE error, and firefox states that the connection was reset while the page wes loading) - same result no page. This error currently prevents a drupal 7.41 admin page from activating or or disabling modules. So this problem is still there. Is it a bug, or a change in PHP's requirements that developers of other software need to re-code to make their code compliant?
 [2016-03-16 11:40 UTC] loebert at netfeld dot de
Found this bug active on debian jessie with PHP Version 5.6.17
Try this little code:

class c2 extends c1
    function demo(){

class c1{
    function demo(){

$demo=new c2();

When calling this code twice (!) - you will get the error. And then change position of c2 and c1: no problems any more.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun May 19 15:01:31 2024 UTC