Cakephp CakePHP → 1.3.5

Comments and changes to this ticket

• 

  paimpozhil July 16th, 2010 @ 09:49 PM

  Thank you for the detailed bug report.. I will try to do my best to solve this..

  But i am guessing this could be bug in the eAccelerator as well...

  When you get time please try in the other optimizers as well like IonCube/ Zend opt/etc

• 

  Mark Story July 16th, 2010 @ 09:49 PM

  • → Milestone set to “1.3.2”
  • → Tag changed from “opcode cache eccalerator crash” to “cakelog, defect, eaccelerator”

  You could always disable error logging as well, or use a better opcode cacher like APC as an alternative. I've used APC many times and never run into this issue, perhaps this is an issue with eAccelerator itself?

• 

  euromark July 17th, 2010 @ 05:11 AM

  eAccelerator works with 1.2 though
  so some change in 1.3 must trigger the error
  isn't the bootstrap include order different now? or something?

• 

  Mark Story July 17th, 2010 @ 09:58 AM

  CakeLog being able to log production errors is different. Of course there have been code changes between the two versions. The fact that the code only breaks when eAccelerator is present, and not when using other opcode caches like APC indicates to me that the issue lies in eAccelerator.

• 

  Mark Story July 18th, 2010 @ 10:24 PM

  • → Milestone changed from “1.3.2” to “1.3.3”

  [bulk edit]

• 

  euromark July 23rd, 2010 @ 04:05 AM

  We did get feedback from our service provider (in german)
  I quickly translate:

  Our Question (regarding the cake1.3 bug):
  "Is there a possibility to use a different Opcode Cache like APC?"

  Answer from the provider:
  "Unfortunately it's not possible. APC proved to be too unstable. eaccelerator is also more performant than apc. your cakephp installation is interestingly the first application,
  which causes problems with the eaccelerator. on our servers to run thousands of different php-applications,
  cms including very complex systems, complex and extensive shops, project management sites and more. everything works fine. we have been successfully using eaccelerator for many years now on all server platforms."

  Due to the fact that only Cake1.3 crashes (both on windows and on linux) and neither any other non-cake-related app nor cake1.2 does point the fact that the bootstrap process of cake1.3 is responsible and needs to be fixed as source of the problem.

  Attachment:

  [Original statement of the provider - in german]

  Question:
  "Gäbe es die Möglichkeit, einen anderen | Opcode Cache wie z.B. APC zu verwenden?

  Answer:
  das ist leider nicht möglich. apc hat sich in unseren tests gegenüber
  eaccelerator als zu instabil erwiesen. eaccelerator ist zudem
  performanter als apc. ihre cakephp installation ist interessanterweise die erste anwendung,
  bei der es probleme in verbindung mit dem eaccelerator gibt. auf
  unseren servern laufen tausender verschiedener php-applikationen,
  darunter auch sehr komplexe cms-systeme, aufwendige und umfangreiche shops,
  projekt management sites uvm. alles einwandfrei. den eaccelerator setzen wir seit vielen jahren auf allen serverplattformen erfolgreich ein."

• 

  Mark Story July 23rd, 2010 @ 08:03 PM

  Also see #817

  Tried to reproduce this issue with the following:

  PHP 5.3.2 (cli) (built: Jul 22 2010 23:38:54) 
  Copyright (c) 1997-2010 The PHP Group
  Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
      with eAccelerator v0.9.6, Copyright (c) 2004-2010 eAccelerator, by eAccelerator
  

  I was unable to reproduce the fatal errors described in the ticket. I was able to use a baked application as well as run the tests.

• 

  euromark July 30th, 2010 @ 03:15 PM

  did you try cached views?
  it mainly happens then

  normal cake cache helper with normal settings (like a few days caching time)

  error logs always state:
  [30-Jul-2010 22:11:00] PHP Fatal error: Class 'CakeLog' not found in H:...\app\tmp\cache\views\home.php (which is the cached view in this case)

  the first time everything is ok, the second time if tries to display the cached view - and BAM...

• 

  euromark July 30th, 2010 @ 03:19 PM

  by the way:

  line 3 is:
  

  $controller =& new CustomPagesController();
  

  the beginning of the cache file
  

  <!--cachetime:1280607056--><?php
      App::import('Controller', 'CustomPages');
      $controller =& new CustomPagesController();
      ...
  

  it seems it cannot create the object? CakeLog is not available either and this causes the fatal error

• 

  Mark Story July 30th, 2010 @ 08:26 PM

  No because you didn't put that in the ticket, and I can't guess how your application is setup. That's why I usually ask for a way to reproduce the issue, which you never gave.

• 

  euromark July 31st, 2010 @ 04:29 AM

  I'm sry - at first it seemed completely random, crashing not just on cached views.
  but i finally could narrow it down to that problem.

  WOW - i just found the fix!
  

      $controller =& new CustomPagesController();
  

  should be
  

      $controller = new CustomPagesController();
  

  in those cache files - and everything works

• 

  euromark July 31st, 2010 @ 04:59 AM

  so in /libs/view/helpers/cache

  change
  

      $file .= '$controller =& new ' . $this->controllerName . 'Controller();
  

  to
  

      $file .= '$controller = new ' . $this->controllerName . 'Controller();
  

• 

  Mark Story July 31st, 2010 @ 10:12 AM

  That & is included for compatibility with PHP4, and will be removed in future versions.

• 

  ADmad July 31st, 2010 @ 10:40 AM

  That & would have been present even in cache files generate by cake 1.2 so its strange when you say the problem showed up only when you switched to 1.3.

• 

  euromark July 31st, 2010 @ 07:12 PM

  yes indeed - thats very strange...
  maybe its the combination of several factors
  but with this minor change it works now on windows - and switching it back and forth proves that this little thing is responsible for getting it to work (or not).
  we need to test it on the productive server next week - hope the results are positive, too.

• 

  euromark August 1st, 2010 @ 03:18 AM

  maybe its a combination of several factors
  like already said, the CakeLog class plays its part as well - which hasnt been there before

  anyway, this little "&" fixes at least the cached pages crash

• 

  djenvert August 1st, 2010 @ 03:13 PM

  I have some problem on a production server with Debian Etch and eAccelerator (0.9.5.2 and 0.9.6).
  The "&" fix doesn't fix it.
  As I have control on it, I disabled eAccelerator, and the problem stopped.
  But of course it's slower now :).

• 

  euromark August 1st, 2010 @ 05:58 PM

  i feared there is more to it... too bad :(

• 

  xbuzz August 2nd, 2010 @ 09:28 AM

  I ran into this issue as well...

  This should fix your problem. Not certain yet of the underlying issue. Hopefully this fix helps narrow done the root cause.

  app/config/core.php
  

  Configure::write('debug', 2); // don't change this. leave at 2 so cake won't crash.
  

  app/config/bootstrap.php
  

  Configure::write('debug', 0); // set debug to 0 in bootstrap, and cake shouldn't crash with eAccelerator enabled.
  

• 

  euromark August 2nd, 2010 @ 09:34 AM

  but this makes your site vulnerable
  errors that happen before the boostrap init will display will full debug output (maybe even paths, sql details or detailed server information etc)...

• 

  Mark Story September 12th, 2010 @ 09:39 AM

  • → Milestone changed from “1.3.3” to “1.3.4”

  [bulk edit]

• 

  Mark Story October 24th, 2010 @ 01:38 PM

  • → Milestone changed from “1.3.4” to “1.3.5”

  [bulk edit]

• 

  euromark November 5th, 2010 @ 02:51 PM

  i can confirm that with php5.3 this issue is resolved

• 

  Mark Story November 5th, 2010 @ 09:03 PM

  • → State changed from “new” to “resolved”

  Since this issue is related to PHP versions and eAccelertor, I'm closing, as this ticket.