Bug #68698 [Com]: Fatal error cannot redeclare [class not being redeclared]
| From: | pegasus at vaultwiki dot org | Date: | Mon, 19 Jan 2015 06:25:38 +0000 |
| Subject: | Bug #68698 [Com]: Fatal error cannot redeclare [class not being redeclared] | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-190052@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=68698&edit=1
ID: 68698
Comment by: pegasus at vaultwiki dot org
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:
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 opcache.so 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.
Previous Comments:
------------------------------------------------------------------------
[2015-01-18 17:49:50] 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-18 05:11:49] rasmus@php.net
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 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?
------------------------------------------------------------------------
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