Bug #68698 [Opn]: Fatal error cannot redeclare [class not being redeclared]

Edit report at https://bugs.php.net/bug.php?id=68698&edit=1 ID: 68698 Updated by: rasmus@php.net Reported by: pegasus at vaultwiki dot org Summary: Fatal error cannot redeclare [class not being redeclared] Status: Open Type: Bug Package: Scripting Engine problem Operating System: Centos 6 64-bit PHP Version: 5.6Git-2014-12-30 (Git) Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2015-01-18 04:27:02] 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:22:29] 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-14 20:04:13] pegasus at vaultwiki dot org I do not get this error consistently. 90% of the time I get this bug instead: https://bugs.php.net/bug.php?id=68453 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-09 07:26:15] krakjoe@php.net We don't have enough information to investigate the problem, please provide reproducing code. ------------------------------------------------------------------------ [2014-12-30 17:01:49] 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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=68698 -- Edit this bug report at https://bugs.php.net/bug.php?id=68698&edit=1