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.
Related
I've been using TBS, OpenTBS and TbsSQL for several years now, always on PHP 5.3.x. I recently decided to try an upgrade to PHP 7.0, and have now run into a strange problem (an error, apparently, but not error text coming back, just:
[TbsSql][Error]: Database error message:
Has anyone else successfully used TbsSQL with SQL Server (the tbssql_sqlserver_odbc.php module, last updated in 2010) in PHP 7?
Is there some known reason why this might not work?
I think I figured it out, so I'll post what I found just in case someone else ran into this weird situation.
I'd apparently had a minor bug in my original code that was doing a $Db->Close() call before I was really done with the connection.
For some reason, in my old environment (where the only difference I think was that I was running a pre PHP 7 version (5.3 or maybe 5.6, possibly it behaves the same on both of those)), subsequent calls using the same $Db connection would succeed, even though, technically, it should've been closed.
As I said, I was using the tbssql_sqlserver_odbc.php module.
Anyway, in PHP 7, once I removed that incorrect Close call, my modules worked as they should.
It's probably a weird obscure situation, but maybe it'll help some one else out someday.
Further note: the symptom I was getting (which is probably generally true of TbsSQL calls, I suppose) is that a call to (e.g.) GetRow would return false instead of an array with the results, as usual.
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).
I tried both ZF 1.12.0 and 2.0.3, then ran this code:
On my computer it didn't work and seemed to stuck in this line:
$videoEntry = $yt->newVideoEntry();
I know that because when I put two echos around that line, only the first got displayed.
The weird thing is that there is no such method called newVideoEntry() anywhere, at all.
And the most annoying thing is that it works completely fine on phpcloud, which turn out to be using ZF 1.11.11, an old version that I can't find anywhere on the internet.
I'm really lost. Any idea? Which version I should use, since they are so much different and incompatible. Any solution for that code ?
Method newVideoEntry() does not exist because it is a magical method. Zend_Gdata_App::__call takes care of that. It creates Zend_Gdata_YouTube_VideoEntry and things go on.
if you want to use the same library as phpcloud all you have to do is to pull the content of the zf library that is hosted on the php cloud server. dont remember where it is exactly but should be in a zend folder on the phpcloud server.
As for the error you get , without the exact error message it is hard to tell what's wrong.
I ran across an interesting issue today. We have an application that utilizes Zend Frameworks caching functionality. A request to this application typically calls a factory method using the following line
$result = call_user_func_array(array("myclass", "factory"), array($id));
The idea is to return an object from the factory method that we can access later on. When we implemented a caching feature, this call just, well, dies. No errors, just a white screen. Nothing in the error log. We can error log the line before ok, but trying to error_log inside the factory method does nothing.
Interestingly enough, changing the line to :
$result = call_user_func(array("myclass", "factory"), $id);
fixes the issue.
We've spent a few hours looking around for bug reports and haven't come up with much to explain this behavior. Thoughts anyone?
I have had issues like this that came down to __autoload not firing properly when a not-yet-loaded class was invoked through a PHP command. No other strategy than dumb trial and error for it as far as I know, just try if a line explicitly invoking the class before the PHP command solves it for you.
$dummy = new MyClassName;
call_user_func_array(array('MyClassName', 'method'), array($id));
unset($dummy);
Which version of php are you using? There was an issue in combining call_user_func_array with ReflectionClass at one point. I'm not sure if it's fixed yet.
Is it segfaulting? Check your 'root' apache logs (outside of any virtualhost) and see whats going on. If that thread is segfaulting you may want to persue that on the PHP mailing lists and/or bug tracker.
Alternately you could try running http in single user mode, in GDB, with a debug-compile of php and see if you can capture it, but thats a lot of work :-)
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.