Skip to content

Classloader can't load every 4th request...?! #3856

Closed
sensi opened this Issue Apr 10, 2012 · 57 comments
@sensi
sensi commented Apr 10, 2012

Some unexpected happens with my symfony2 app in production environment.
I always getting 500 Internal Sever Error with following log message:
PHP Fatal error: Class 'Doctrine\Common\ClassLoader' not found in /var/www/cosamui/app/autoload.php on line 47

Code on line 47:
$classLoader = new \Doctrine\Common\ClassLoader('DoctrineExtensions', DIR . '/../vendor/DoctrineExtensions');

I ensured that the doctrine extension exists... And It also work's some times. But every 5 request I get this error and a plain site :(

I've tried to comment out the this line above, because it's not really necessary... But if i to that it does the same... But I get this error:
Fatal error: Class 'Doctrine\Common\Annotations\AnnotationRegistry' not found in /var/www/cosamui/app/autoload.php on line 49

Now the AnnatationRegistry can't found at every 5 request...

Does anyone know what's going on there??

@beberlei
@sensi
sensi commented Apr 10, 2012

I've checked my phpinfo and there is no apc-cache active:
php -r 'phpinfo();' |grep apc
suhosin.apc_bug_workaround => Off => Off

Or is there an other place to check that?

But I think your on the right way, to look up at the apache config. But I've nothing special configured. It's nearly the default config after apt-get install ...

It seems that current build of PHP makes troubles with that. Because the previous version I used, works without any issues.
But after updating my server this issues appears.

Current PHP-Version:
PHP 5.3.3-7+squeeze8 with Suhosin-Patch (cli) (built: Feb 10 2012 13:05:56)
Apache/2.2.16

@sensi
sensi commented Apr 10, 2012

Ok i figured out that every 11 request the error appears... But I don't find anything at apache config which get's triggered.

@sensi sensi closed this Apr 10, 2012
@sensi
sensi commented Apr 10, 2012

I've figured out the problem. The default apache cfg has following lines:
MaxKeepAliveRequests 100
KeepAliveTimeout 15

If now set this values an the issue was solved.

MaxKeepAliveRequests 0
KeepAliveTimeout 30

The problem in my case was that about 10 clients with the same ip logged in into my application and worked with it...
And after the MaxKeepAliveRequest was reached the client gets at the next time an 500 error.

@sensi sensi reopened this Apr 11, 2012
@sensi
sensi commented Apr 11, 2012

Ok, that doesn't fix my issue. I have also tried to deactivate the KeepAlive.
And i figured out that every 11 Request the PHP Fatal error occurs.

There are also a notice an warning.:
PHP Notice: Trying to get property of non-object in /var/www/cosamui/app/bootstrap.php.cache on line 1220
PHP Warning: Invalid argument supplied for foreach() in /var/www/cosamui/app/bootstrap.php.cache on line 1220
PHP Fatal error: Class 'Doctrine\Common\ClassLoader' not found in /var/www/cosamui/app/autoload.php on line 47,

And cache like apc is not installed.

@sensi
sensi commented Apr 11, 2012

This command fix my troubles:
apt-get install php5-sqlite

I hope this monolog helps someone who went some issue then me. ;)

@ruian
ruian commented Apr 19, 2012

ping @fabpot issue OK, can be closed.

@fabpot fabpot closed this Apr 19, 2012
@sensi
sensi commented Apr 19, 2012

Hm I'm sry to tell you that the issue allready exists.

@Tobion
Symfony member
Tobion commented Apr 19, 2012

Why close?

@stof
Symfony member
stof commented Apr 19, 2012

Well, you are the one who said it was fixed 8 days ago...

@ruian
ruian commented Apr 19, 2012

it's closed because @sensi said he found a solution to his problem

@Tobion
Symfony member
Tobion commented Apr 19, 2012

But the reason for crashing without sqlite doesn't seem to be solved. But maybe it's his special configuration we cannot fix.

@sensi
sensi commented Apr 24, 2012

Final Solution to my issue:
APC-Cache was missing! In my prod environment I've not so much resources and there are more clients...
So if you have only a poor server for your app you've to use the ApcCacheClassLoader instead of UniversalClassLoader...
I also tried to use the cache mechanism from UniversalClassLoader but in my case without success.

@PomepuyN

I have exactly the same problem with APCCache and sqlite installed and enabled.
Exact issue : Fatal error: Class 'Doctrine\Common\Annotations\AnnotationRegistry' not found in /path/to/site/app/autoload.php on line 45
The weird thing is that it doesn't happen for days then start to happen really soon on short periods.

@sensi
sensi commented Apr 24, 2012

@PomepuyN Yeah same issue like me... Do you use APCCache?

Be sure to include following lines at top of your autoloader.php:

require __DIR__.'/../vendor/symfony/src/Symfony/Component/ClassLoader/ApcUniversalClassLoader.php'; 

//use Symfony\Component\ClassLoader\UniversalClassLoader;
use Symfony\Component\ClassLoader\ApcUniversalClassLoader;

use Doctrine\Common\Annotations\AnnotationRegistry;

//$loader = new UniversalClassLoader();
$loader = new ApcUniversalClassLoader('m3_cache');

Notice you've to install apc package and the zend-optimzier. In my case it looks like:
CentOs:
yum install php53-zend-optimizer.x86_64
yum search apc
yum install php-pecl-apc.x86_64
Debian/Ubuntu should be equal but with apt-get install ...

@PomepuyN

All is configured as you describe. The only difference is that I don't use zend optimizer. Is it mandatory ?

@sensi
sensi commented Apr 25, 2012

Im not sure but I think I've read somewhere that zend optimizer is recommended to work with apc-cache correctly. And in my case it was neccessary. Before I tried without zend-optimizer, the same error occurs. But I don't check if apc was running correctly, without zend-optimizer.

So i recommend to install the zend-optimizer if possible. Which OS you're using?

@PomepuyN

It's a debian distribution.
I will try to install zend optimizer next week.

@sensi
sensi commented May 2, 2012

@PomepuyN: And does it work now?

@lautr
lautr commented May 2, 2012

I'm having the same problem, the application (currently still in development) runs fine for a day or two, then the error will start popping up (ever 4th impression with debug, every 8th without debug) I think the Problem is somehow linked to APC but not really sure why and how.

I'm using symfoyn 2.0.13 and this is my apc config:

~ cat /etc/php5/apache2/conf.d/apc.ini
extension=apc.so
apc.enabled=1
apc.ttl="7200"
apc.user_ttl="7200"
apc.shm_size="512"
apc.user_entries_hint="6144"
apc.shm_segments=1
apc.include_once_override=0

Issue should be reopened

@sensi
sensi commented May 2, 2012

@lautr: Sry can't reopen the issue again. And here is my config:

; Enable apc extension module
extension = apc.so
apc.enabled=1
apc.shm_segments=1
apc.shm_size=64M
apc.num_files_hint=1024
apc.user_entries_hint=4096
apc.ttl=7200
apc.use_request_time=1
apc.user_ttl=7200
apc.gc_ttl=3600
; apc.filters so that files are only cached if matched by a positive filter.
apc.cache_by_default=1
apc.filters
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.file_update_protection=2
apc.enable_cli=0
apc.max_file_size=1M
apc.stat=1
apc.stat_ctime=0
apc.canonicalize=0
apc.write_lock=1
apc.report_autofilter=0
apc.rfc1867=0
apc.rfc1867_prefix =upload_
apc.rfc1867_name=APC_UPLOAD_PROGRESS
apc.rfc1867_freq=0
apc.rfc1867_ttl=3600
apc.include_once_override=0
apc.lazy_classes=0
apc.lazy_functions=0
apc.coredump_unmap=0
apc.file_md5=0

Apc config manual: http://www.php.net/manual/en/apc.configuration.php

@lautr
lautr commented May 3, 2012

well thats basically (including default) values the same configuration i use (only with an higher shm_size) we now deactivated apc to test if it really is at fault, unfortunately i don't really know which conditions must be meet to make the problem show up.

Btw, i dug a little deeper, the Problem seems to be that classes defined in the bootstrap.php.class (like the universal class loader / apc class loader) can't write / read their own properties every 4th Requets (or so) - so the array of namespaces is empty, so he can't fine 'Doctrine\Common\Annotations\AnnotationRegistry' .

@sensi
sensi commented May 3, 2012

Are you using zend optimizer? In my case it runs only correcly with the zend-optimzer.

@PomepuyN
PomepuyN commented May 3, 2012

Sorry for the late answer.
I installed zend optimizer yesterday. The error didn't happen since then. But as it has been really intermittent, I'm still waiting a bit to know if it has really gone.

@sensi
sensi commented May 3, 2012

Ok thx for the info.
@lautr: seems that you should also try to install zend-optimzer... Or allready installed?

@lautr
lautr commented May 3, 2012

the problem just started to appear again (apc disabled), we could try to enable zend optimizer but it sounds a little bit like a shot in the dark to me :-(

@sensi
sensi commented May 3, 2012

Yes that's the point it appears the first time in my case (without any apc cache...)
It seems that there are to many classed to load for every request. And if there are more users which are using the application then the load error appears.
Yeah but in my case the shot in the dark was best way to fix it ;) Because all my other work just failed...
OMG that's really tricky!!

@mvrhov
mvrhov commented May 3, 2012

Installing ZendOptimizer alongside of APC doesn't make any sense. APC should work standalone. Now the APC comes with apc.php script. How badly is memory fragmented when you start getting the errors?

@lautr
lautr commented May 3, 2012

Like i said, the Error starts to happen without apc so there is no memory fragmented, also it seems once the problem starts it happens in all php applications on the Server, but it only starts to happen when people use symfony.

I'm currently using PHP Version 5.3.3-7+squeeze8 with apache prefork mod_php

@sensi
sensi commented May 8, 2012

hm that's correct. But why it works in my case. I have check my memory and I've also not enough. If there are more users using the application my swap space is being used.
But without zendoptimizer and apc cache my app always fails at every 4 - 10 request. So it seems that with the newer php versions and os versions it give troubles with symfony2 apps.

Because with my old lenny disb. and php 5.3.2 that issues doesn't occur!

@PomepuyN
PomepuyN commented May 8, 2012

Well, it seems that the issue has been corrected by the installation of Zend optimizer.

@lautr
lautr commented May 8, 2012

It seems that something symfony does corrupts a php Process that after that always throws that error ( Classes not being able to read their own properties ) every time its used (explaining the weird ratio the error occurs and the time delay it takes to appear after a reboot) if you use prefork lowering MaxRequestsPerChild to > 10 will decrease the chance of this Error Appearing considerably - but thats obviously not configuration for a production system

We have changed to dotdeb and updates to PHP Version 5.3.11-1~dotdeb.0 - since then ( 12 hours ) the Error has not appeared.

@sensi
sensi commented May 8, 2012

Yeah I also tried to change MaxRequestPerChild value. But as you say not for a production system. And my server doesn't have ressources for this option....

I hope for you that it work's no with the dotdeb repos. I've no experience with the new php versions from the dotdeb repo.
So it's interesting if that solution works. Please keep us up to date if it works correctly.

@ghost
ghost commented May 24, 2012

As merging issue does not work (see #4348 ) I post here what I did in the other :

For a week now, sometines, the namespaces property in bootstrap.php.cache is null, which trigger this error:

Notice: Trying to get property of non-object in app/bootstrap.php.cache on line 1211
Warning: Invalid argument supplied for foreach() in app/bootstrap.php.cache on line 1211
Notice: Trying to get property of non-object in app/bootstrap.php.cache on line 1225
Warning: Invalid argument supplied for foreach() in app/bootstrap.php.cache on line 1225
Fatal error: Class 'Doctrine\Common\Annotations\AnnotationRegistry' not found in app/autoload.php on line 35

And after a few hours, without doing anything special, everything returns to normal, until the error reappears.
What makes me create a bug is that, a little annoyed by this error, I completely deleted my project, downloaded the latest symfony version, re-installed my vendors to get back on a clean. But the error is still there...

I checked three times, the class AnnotationRegistry exists in my project.
It can not be a issue between incompatible version bundle, since it is a clean symfony that is installed.

Is there a hidden cache in symfony | doctrine that I could empty ? How can it be that even after reinstalling my symfony version, the error is still there? More generally, how is it possible that the namespaces property is empty in bootstrap.php.cache ?

Other message, 3 days later

Yes I guess it's PHP. Strange behavior within bootstrap.php.cache, var_dump($this) shows namespaces set, but var_dump($this->namespace) throw the "Trying to get a null object" or something like that. So, removed my PHP 5.3.2 dotdeb build with mod_fcgid, with PHP 5.3.5 and PHP-FPM, and now it works like a charm ( Adapted from this french how-to, http://blog.myprod.net/2010/08/14/apache2-suexec-fastcgi-php-5-3-3-fpm-cache-opcode-apc/ )

@pdjcollins

[Originally posted in #4348]
Same problem is happening with our S2 application. Intermittently, getting:

PHP Warning: Invalid argument supplied for foreach() in /home/didadm/20120524.140245/apps/dids/app/bootstrap.php.cache on line 1206, referer: http://dids.i.com/site/vox/1
PHP Notice: Trying to get property of non-object in /home/didadm/20120524.140245/apps/dids/app/bootstrap.php.cache on line 1220, referer: http://dids.i.com/site/vox/1
PHP Fatal error: Class 'Doctrine\Common\Annotations\AnnotationRegistry' not found in /home/didadm/20120524.140245/apps/dids/app/autoload.php on line 40, referer: http://dids.i.com/site/vox/1220

@pdjcollins

I put this out to the S2 community and @mr_r_miller suggested a couple of possible areas to investigate.
1. using annotations for DI
2. APC

I'm not using annotations for DI, so I'm currently looking at the apc side of things.
for info: our production server is running PHP 5.3.3-7+squeeze3 with Suhosin-Patch

@lautr
lautr commented May 25, 2012

@pdjcollins its not APC (tested that, see comments above) We solved the Problem by switching from 5.3.3-7+squeeze8 to 5.3.11-1~dotdeb.0

@pdjcollins

@lautr thanks for clarifying. I take it you haven't seen this problem at all then since moving to 5.3.11-1~dotdeb.0 ? For me this was really frustrating. I hadn't seen the problem at all until the day we rolled to production - and then it just "happened" on both dev and live servers !

@lautr
lautr commented May 25, 2012

@pdjcollins i know what you mean, luckily we saw the problem on the development servers before we went live, as a solution until you change the PHP Version could be to set the MaxRequestsPerChild in your apache Configuration lower then > 10 - that should decrease the Chance of the Error occurring rapidly, but also will put more load on the Servers. And yes, the Problem no longer occurs with the new php version

@pvcnt
pvcnt commented May 26, 2012

I've just experienced the same issue just a few hours after launching the new version migrated under Symfony of my website... Not really fun. I've upgraded php5 to the squeeze9 and for now the problem has disappeared, but I'm not sure it will not come back again (maybe it's just the apache reload that has "fixed" the issue).

Does anyone has an other solution than switching to the deb0 package?

@pvcnt
pvcnt commented May 27, 2012

The squeeze9 package is buggy too. This is really a PHP bug (50027 et 52083). Reloading Apache config fixes temporary the bug... for a few hours.

@fabpot
Symfony member
fabpot commented May 27, 2012

I have looked at the referenced bugs mentioned by @Vincent-P. Does it mean that we should raised the minimum version of PHP to 5.3.4?

@sensi
sensi commented May 27, 2012

Hm looks so. An older version of PHP also work's fine. With previouse php (5.3.2) version this issue doesn't occured. But it's not available anymore in any package repository for debian or centos.

So for people who are using php > 5.3.2 it's recommended to switch version min. 5.3.4. Version beetwen seems to be corupted by the php bug's figured out by @Vincent-P.

@fabpot fabpot reopened this May 27, 2012
@fabpot
Symfony member
fabpot commented May 27, 2012

Can we list the versions that do not work?

@martinezleoml

It doesn't work with 5.3.3 php5 version, which is the last stable version in the debian squeeze package repository, as @sensi said. I've experienced the same bug.

@sensi
sensi commented May 27, 2012

Doesn't work :
PHP 5.3.3-7+squeeze8 with Suhosin-Patch (cli) (built: Feb 10 2012 13:05:56) Apache/2.2.16
PHP 5.3.10 (cli) (built: Feb 3 2012 08:20:28)

@martinezleoml

Doesn't work:
PHP 5.3.3-7+squeeze9 with Suhosin-Patch (cli) (built: May 8 2012 10:41:34)

@ghost
ghost commented May 27, 2012

Doesn't work
PHP 5.3.2 dotdeb

@lautr
lautr commented May 31, 2012

@Vincent-P reloading the apache helps because the corrupt proccess is gone, if you can't update your PHP Version lower the MaxRequestsPerChild Value
@fabpot Doesn't work in 5.3.3-7+squeeze8, works in 5.3.11-1~dotdeb.0

@fabpot fabpot added a commit that closed this issue Jul 13, 2012
@fabpot fabpot raised the minimum version of PHP to 5.3.4 (closes #3856)
We've raised the minimum version of PHP because of a PHP
bug before 5.3.4:

https://bugs.php.net/bug.php?id=52083
https://bugs.php.net/bug.php?id=50027
2dcc448
@fabpot fabpot closed this in 2dcc448 Jul 13, 2012
@fabpot fabpot added a commit that referenced this issue Jul 15, 2012
@fabpot fabpot Revert "raised the minimum version of PHP to 5.3.4 (closes #3856)"
This reverts commit 2dcc448.
cd24e6e
@tiagojsag

Just came across this one on one of my client's servers, with symfony 2.0.16 and PHP 5.3.3. Since I doubt my client will want to upgrade his php version, is there any symfony version I can roollback to that will allow me to avoid this problem? thanks

@stof
Symfony member
stof commented Aug 3, 2012

@tiagojsag No. There is simply no workaround in PHP for this bug. When the engine deletes your objects, the code written in PHP cannot fix it. the only workaround would be to rewrite Symfony without objects...

@jmikola
jmikola commented Oct 1, 2012

@fabpot: Since the original fix was reverted, perhaps this should be re-opened pending more investigation?

Exercise.com is suffering from this in PHP 5.3.9 (CentOS). OpenSky is currently using PHP 5.3.14 (binary from a custom Fedora repository) and hasn't experienced the problem. That would agree with the above comments:

@sensi: Doesn't work: PHP 5.3.3-7+squeeze8 with Suhosin-Patch (cli), PHP 5.3.10 (cli) (built: Feb 3 2012 08:20:28)

@lautr: Doesn't work in 5.3.3-7+squeeze8, works in 5.3.11-1~dotdeb.0

If something in the 5.3.11 release fixed this, I can't make it out from the changelog.

@jmikola
jmikola commented Oct 1, 2012

An additional point to consider might be APC. Exercise.com has 3.1.3p1 and OpenSky has 3.1.6. The APC changelog includes some fixes between those releases for file path resolution.

@lautr
lautr commented Oct 2, 2012

@jmikola afaik the problem is not related to APC, at least i was able to observe it on a Server where APC was disabled

@linibou
linibou commented Dec 13, 2012

i have this kind of trouble too, i think a good thing to try is change "MaxRequestsPerChild 0" in apache settings. If MaxRequestsPerChild is set to 0, apaches processes will serve an infinite number of requests without being refreshed. When dealing with php, refreshing processes can avoid troubles due to memory leaks. So try to raise this setting (500 or 1000) but don't set it too low, it could be a performance killer. Hope this will be helpful :-)
Regards.

@herdani
herdani commented Jan 24, 2013

FYI, got the same issue on several servers: all the Debian one's, with the latest supported PHP version (5.3.3)
I've upgrade PHP to 5.3.20 (through the DotDeb Debian repository) and everything seems fine now on all my servers

@pitpit
pitpit commented Feb 19, 2013

I got the same issue on Centos, php 5.3.3-14...

@priestor priestor referenced this issue in doctrine/DoctrineMongoDBBundle Apr 19, 2013
Closed

Production environment hydrator error #187

@mmucklo mmucklo pushed a commit that referenced this issue May 23, 2013
@fabpot fabpot raised the minimum version of PHP to 5.3.4 (closes #3856)
We've raised the minimum version of PHP because of a PHP
bug before 5.3.4:

https://bugs.php.net/bug.php?id=52083
https://bugs.php.net/bug.php?id=50027
732b17f
@mmucklo mmucklo pushed a commit that referenced this issue May 23, 2013
@fabpot fabpot Revert "raised the minimum version of PHP to 5.3.4 (closes #3856)"
This reverts commit 2dcc448.
5a55664
@hackzilla hackzilla pushed a commit that referenced this issue Dec 10, 2014
@fabpot fabpot raised the minimum version of PHP to 5.3.4 (closes #3856)
We've raised the minimum version of PHP because of a PHP
bug before 5.3.4:

https://bugs.php.net/bug.php?id=52083
https://bugs.php.net/bug.php?id=50027
498c2da
@hackzilla hackzilla pushed a commit that referenced this issue Dec 10, 2014
@fabpot fabpot Revert "raised the minimum version of PHP to 5.3.4 (closes #3856)"
This reverts commit 2dcc448.
bc4016b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.