Cannot redeclare class sfconfig - php

I am running Symfony (1.2.9) with PHP Version 5.2.11 on Windows XP.
I have APC installed (Version 3.0.19)
I can run PHP script to prove that apc is working correctly (works). However, when I try to use APC calls in a symfony action, I get this error (in the apache error.log file):
[apc-error] Cannot redeclare class sfconfig
Which promptly crashes Apache.
I tried using the Symfony sfAPCCache wrapper, and then directly calling the apc_* functions - the result is the same. Does anyone know why this is happening ?

Checkout these threads:
http://pecl.php.net/bugs/bug.php?id=16860
http://old.nabble.com/APC-under-WinXP-crashes-td25872662.html

Today this error happened to me, too, and I became aware of why it can happen (among possible other reasons).
APC correctly identifies every class by a fully qualified name, which includes the classes namespace. Unfortunately you can end up referring to the same class with various names.
For example:
I had a wrong "use" statement in my code, importing a non-namespaced class as if it had been inside a namespace.
The class, say "MyClass" was in namespace "\", meaning that its correct and fully qualified name was "\MyClass".
At some point the class was referred to by its unqualified name "MyClass", and got autoloaded. In another file I (wrongly) referred to the class with a namespace prefix in a use statement, say "use \SomeNamespace\MyClass;". Consequently the class was (again) passed to my global __autoload() method, but with a different name. To make it worse, the autoload method was smart enough to find the class anyway.
Instantly, my script stopped working and all that happened was APC writing "[apc-error] Cannot redeclare class ..." into the Apache Web Server error.log. My pages were no longer available.
This is not an APC bug whatsoever, but simply correct behaviour.
In my case it helped to temporarily disable APC (so that my script would be run regardless of the conflict), and hook an echo statement into my __autoload function producing a list of the parameters passed. The class loaded with a wrong name would show up quickly, and I could fix it and reenable APC.
Hope this helps someone.

Ive had this error before unrelated to APC and it always helped to not only run the cache:clear but also to check and make sure all files were deleted from the cache dir.

I was living the same situation on my development windows
system with php 5.2.11 and several apc versions. Same
situation as described, with stat=0 everything works, but
when I set stat=1, apache crashes with error "cannot
redeclare class [some class]". The code is working on a
different windows system, beside it is live on a heavily
loaded linux production server for months. I'm %100 sure
there is no bug related to apc. It started on my machine
after I reinstalled my OS.
I spent some time commenting out some class includes and
realized that it works with some include files but not with
specific ones. I checked my code there is no noticeable
difference on the class differences.
Then I saved all of my include files with adding some
additional whitespaces with Zend Studio's editor. It looks
stupid I know but it works!!! I'm working on the project
with several people and using svn and everybody uses
different text editors like notepad++, editplus etc...
However I couldn't reproduce the error by trying save the
file with some different editors with different configs like
ansi, utf8 with/without byte-mark ordering etc. But I'm sure
my problem is something related to file format (encoding,
pc/unix mode). I'd like to reproduce the error and want to
give more detailed info but I tried my solution on another
project with same problem, it works either.
I hope I could give another perspective to the issue.

What solved this for me was making sure my requires had the same path.
For example, the error I got was:
[apc-error] Cannot redeclare class someClass
In file A I had the following:
require_once '/path/to/someClass.php';
In file B which resides in the same directory as someClass.php I had the following:
require_once 'someClass.php';
I believe that APC caching didn't understand they were the same file because the path was specified for one and not the other.

Related

Magento - "Class string does not exists" error - only on production

So here's the situation. It is PHP 7.4, Magento 2.4.3-p1
On the production server, an error is showing up on the exceptions.log. It reads as follows:
Class string does not exist at /var/www/public/vendor/magento/framework/Webapi/ErrorProcessor.php:208, ReflectionException(code: -1): Class string does not exist at /var/www/public/vendor/magento/framework/Reflection/MethodsMap.php:166)"} []
I happens daily on the production server, but it does not happen on staging, dev, and worse, I cannot replicate the error on local.
The method gets called when loading a PLP, PDP, homepage and checkout&shipping (maybe on even more places) and cache has been cleared (locally). On prod, I assume when someone visits the page for the first time.
I've put a breakpoint in the method. The method seems to load a bunch of interfaces and caches them. Some of them are:
Magento\Tax\Api\Data\TaxDetailsInterface
Magento\Catalog\Api\Data\ProductRenderInterface
\Magento\Catalog\Api\Data\ProductRender\ButtonInterface
etc...
Things I have tried
Running the master branch, with the production database, and in production mode. Nothing happens.
I've added a logger to the method in question. It just shows the interface being called, and on which page.
Since I think this has something to do with the phpdocs, I have tried messing around with the various phpdocs on the loaded interfaces, and the classes which implement the interfaces, but no luck.
UPDATE:
In the meantime, the project has been updated to M2.4.4 and PHP 8.1. Error is no longer present.
Any ideas? Cheers!

Is it okay to use chdir() in a shutdown function?

I noticed my Autoloader was not working properly on destructors (after die;), because PHP changes the current directory on shutting down.
was:
D:\www\arsenal
got changed to:
C:\wamp\bin\apache\Apache2.2.21
I don't even know why it does that. I solved the Autoloader problem using realpath but was wondering what kind of other problems it may cause.
So, is it safe to use chdir to change it back in a function registered with register_shutdown_function? I tested it and totally solved the Autoloader problem, as well as realpath did (the shutdown function gets called before the destructors, don't know why either).
The catch is that i'm afraid of the consequences. I don't even know if PHP behaves this way in other platforms. I would really like to have more information on the subject.
I'm on Windows 7, using WAMP 2.2 (PHP 5.3.8, Apache 2.2.21).

How does APC optcode cache identify a class?

I'm running a one instance Apache setup with multiple virtual hosts that runs different versions of the same code base.
By this I mean that one virtual host can server one version of a class and another can server second version of the same class (same namespace, same name).
/file/path/host-a/MyClass.php
/file/path/host-b/MyClass.php
Sometimes I get an exception that shows me that one of the virtual hosts uses the "wrong" version of a class. E.g. on host b I get an exception with file path to script of /file/path/host-a/MyClass.php
I thought that the APC optcode cache used the file path, at least as a part of the key, but I'm fearing, that it only uses a qualified class name like:
My\Namespace\MyClass
Is that the case? Please point to any documentation on this subject if possible.
Answer
Though is was unable to find any documentation on the answer to this question php - APC opcode caching on different file versions explains that the APC optcode cache in fact does use the path of the file that defines the class to distinguis classes with the same name.
Debugging
After #hakra pointed out to me the behaviour of APC, I was able focus my efforts on the class loader. My class loader uses memcached as cache for storing the class paths. It turned out that the code for building cache keys were the cause of the problem - and not the APC which it seemed to be.
So should you be in a similar situation where your see that the incorrect "versions" of a class is loaded ensure that you class loader is working as expected. One obvious clue is of course the file path of the problem class.

Namespaces in php 5.2

I've done little web using namespaces. I have it in my computer and i'm about to moving it to free hosting that uses php 5.2. Syntax highlighter for php 5.2 interprets them as errors.
Are namespaces supported by php 5.2?
If not is there any way how to use them with little changes to existing code?
Namespaces are not supported prior to 5.3. There isn't really a way to adapt for them into 5.2 unfortunately.
Namespaces are only available as of 5.3
At least in the case of classes, you can use the class_exists function to check if a class has already been defined with a like name within the global namespace. Coupled with the __autoload() function, you can create one universal alias and have the system check for both classes named by the original name as well as the name with some kind of extra identifier prepended. I'll use "ns" as an example.
function __autoload($class){
try{
require_once('ns'.$class.'.php');
}catch(Exception $e){
echo 'The class is unavailable in pseudo-namespace as well as global';
}
}
Just make sure the require path points to wherever you keep your models. You could use a different folder instead of the alias as well.
This way, any duplicate classes can be put into files separate from the main execution that are only included if they don't exists in the global. Though this doesn't strictly fix the problem of having to physically rename the classes, it will allow you to put your definitions in different directories for versioning purposes etc.
Namespaces are available in PHP as of
PHP 5.3.0.
Source: http://www.php.net/manual/en/language.namespaces.rationale.php
http://www.php.net/manual/en/language.namespaces.rationale.php
Namespaces are available in PHP as of PHP 5.3.0.
Ive just come across this problem, ive developed an image upload script myself and added some third party code to aid image processing (cropping) but they use namespaces, works fine on my develoment machine, but when i uploaded to the live server i get a Parse error.
Luckily my host supports php 5.3 and 5.4, so ive asked them to change it to 5.3 for me, im hoping that will solve the problems im having, simply removing the namespaces made the script fail :(
Paul

Existing Class not found using XCache and PHP 5.3.2

I'm getting the weirdest problem using XCache and PHP 5.3.2 there is a class 'Vb_Post' that won't be loaded by PHP and throws a Fatal Error:
Fatal error: Class 'Vb_Post' not found in /Users/mario/Sites/m.techspot/app/models/Vb/Comments.php on line 5
If I run the same code with PHP 5.2 and XCache 1.2.2 or PHP 5.3.2 and APC everything runs fine. Is there a workaround/fix to this and does anyone know if this is a known issue, I've googled like crazy and haven't been able to come up with any solutions, I've read some people having similar issues using php 5.3.2 and APC but it looks like I'm suffering from the opposite.
I don't know exactly when this issue appeared but it worked fine until a week ago, and there were no major code change. The same problem happens in my development computer and on the server, both running the same mentioned software.
I'm pretty sure it has something to do with XCache since the first time it runs everything is OK, the error appears on subsequent requests.
Could it be that there's some hidden character that's causing this issue?
OK I found a work around for this problem. At the top of the Vb_Post class I was loading some classes that also referenced the Vb_Post class, apparently it was causing some kind of conflict that prevented the class from being loaded when cached.
The fix:
Moving the require_once('SomeClass.php') inside the class just before actually using it.
...
public function someAction()
{
require_once('SomeClass.php');
var $sc = new SomeClass();
...
}
...
So, after battling with these for about a week, this is the best solution I've come up with, hope this helps someone else.

Categories