php 5.4 fatal error, Allowed memory size of 83886080 bytes exhausted

Hi, I upgraded a server to php 5.4 and I've been getting these php fatal errors ever since.

09-Apr-2013 05:43:33 America/Denver] PHP Fatal error: Allowed memory size of 83886080 bytes exhausted (tried to allocate 3050946969 bytes) in /home/MYDOMAIN/public_html/store/includes/functions/html_output.php on line 62
[09-Apr-2013 05:43:33 America/Denver] PHP Warning: require(includes/classes/db/mysql/query_factory.php): failed to open stream: No such file or directory in /home/MYDOMAIN/public_html/store/includes/functions/sessions.php on line 59
[09-Apr-2013 05:43:33 America/Denver] PHP Fatal error: require(): Failed opening required 'includes/classes/db/mysql/query_factory.php' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/MYDOMAIN/public_html/store/includes/functions/sessions.php on line 59

It's in sessions.php where there is no db object defined, so it tries to include the db class. But that is failing. Says it's a bug fix for php 5.2.

I tracked one occurrence down to a session issue with the authorize.net sim callback. In the header.php for checkout_success, I put a session_write_close() just before the exit and that stopped the fatal error in that situation. But here it is occurring again somewhere else.

In query_factory, there is a session existing when I log just before the failing include.
If I change the include to be a full file path, the include of the db class succeeds but it fails saying that class Base doesn't exist, so something is very wrong there. Some chain of includes is failing somehow.

Any ideas on how to debug this situation? I'll have to find which url is causing this fatal error and try seeing how far it's getting and where it's occurring by using error log statements. I haven't been able to cause it to happen locally, or when a debugger is attached to server. Any ideas?

Are these includes depending on the current directory set to anything in particular? I'm using php-fpm to run php from apache 2.4.

thanks much

Sounds exactly like custom code (or an addon with a bug) that's gone into an endless loop while iterating through a set of database results because it's missing the call to MoveNext() within the while() loop.

The files mentioned are merely messengers; highly unlikely they're the cause of your problem, unless you've altered them from their original contents.

Thanks, that helps, I didn't think of that - php is calling the session_write because it's killing a thread that's either timed out or used too many resources. And perhaps many of the classes are garbage at that point, overwritten in memory etc.

We don't have many customizations but I'll check them all. I don't think it's the database thing or infinite loop or we'd have problems with our store. Our store is running fine except for this random bug that occurs a few times a day. It used to only occur during the authorize.net sim callback, but now I have to track down what's causing it again.

thanks

A great place to start: http://www.zen-cart.com/wiki/index.php/Troubleshoot_-_Diagnosing_Obscure_Issues

Hi, sorry to jump in, but I'm having pretty much the same problem. I'm using Zen Cart version 1.5.1, with PHP 5.2 everything is fine, when I switch to PHP 5.4, everything is still fine apart from:

When a customer tries to log in (on "main_page=login", enters email address + password + click "log in" button) the screen goes blank. Refresh with F5 and everything is fine, they are logged in and can access orders etc. The only issue is the blank screen, and obviously customers won't know to refresh.

The log file is pretty much as above: "[09-May-2013 20:19:01 Europe/Berlin] PHP Fatal error: Allowed memory size of 94371840 bytes exhausted (tried to allocate 746615801 bytes) in /homepages/1/d205539884/htdocs/store/includes/functions/html_output.php on line 62".

Any ideas where to start looking? The customer table in the database is only half a MB which doesn't seem too large, and I don't think there are any mods which would affect this. Also it doesn't happen at all with PHP 5.2.

I had this same Fatal Error show up on a different site with different server, different Cent OS version, and almost no cart customizations. Traced it down to the last redirect in the header.php for the login page. Was able to do a backtrace on an apache segfault core dump and saw a Zend error reading a constant. I wasn't able to debug it more w/o recompiling php with debug symbols etc etc.

Also, it seemed to depend on cookies - if I had logged in once (refresh after fatal error), then it would logout/login w/o error. But starting w/o cookies seemed to always make it error.

I was able to duplicate the crash on a virtualbox linux setup too. If I commented the code in login header.php for merging the carts, it segfaulted, if left in it was a Fatal Error. So something was hosed earlier probably. This is w/o any opcode cache. Happens with apache 2.2 and 2.4, one is DSO and one is php-fpm. So I think we have a php error showing up in 5.4.14.

Went back to php 5.3.23 and all is fine now - no errors at all. That's the only solution I know for now.

I was using php from the Remi repository for centos/redhat. When there's an update I'll try again.

here's the call trace from the segfault:
(gdb) bt
#0 0x006604f5 in ?? ()
#1 0x04c34090 in ?? () from /usr/lib/httpd/modules/libphp5.so
#2 0x04a778ff in _zval_copy_ctor_func (zvalue=0xb75d6e8c) at /usr/src/debug/php-5.4.14/Zend/zend_variables.c:123
#3 0x04abc2fb in _zval_copy_ctor (execute_data=<value optimized out>)
at /usr/src/debug/php-5.4.14/Zend/zend_variables.h:45
#4 ZEND_FETCH_CONSTANT_SPEC_UNUSED_CONST_HANDLER (execute_data=<value optimized out>)
at /usr/src/debug/php-5.4.14/Zend/zend_vm_execute.h:22396
#5 0x04ae64a6 in execute (op_array=0x1ad3d58) at /usr/src/debug/php-5.4.14/Zend/zend_vm_execute.h:410

Have to admit I'm a novice with this stuff and a lot of it goes over my head. One thing I've noticed which may or may not be relevant - with PHP 5.2, when a customer logs in, the page that loads up is the store home page (unless they have saved cart contents). With PHP 5.4, after the blank screen and refresh, the page that loads is "main_page=account" instead of the store home page.

Also, I have another site with the same server settings, zen cart 1.5.1 again, more or less the same zen cart settings + mods, but works fine on PHP 5.4. Logging in brings up the store home page on that site.

I've tried deleting all CUSTOM template files so the defaults were used, still the same problem. I've looked at files in the modules/pages folders for the login + account pages, compared them to the other site which works ok, and there are no differences.

I'm completely stumped now. I was hoping to switch to PHP 5.4 so I can upgrade to a different hosting package, which doesn't support older versions of PHP. So frustrating as this is the only thing holding me back. :huh:

Just realised my last post was pretty useless, sorry. Login takes the customer back to where they were before, so in my case shop home page. F5 on the blank login screen takes the customer to their account page, as that is what is supposed to happen if someone tries to "log in" while already logged in. :blush:

So the question is, what causes the blank page error after login, even though the login works (they are logged in after F5 refresh)?

you need to check your php error log files and see what they say. with 1.5.1 it's in the logs folder.
If there's no errors, it may be that apache crashed and that would be in the system error logs - your host should be able to tell you where to find those.

The error log is the same as mentioned in my first post.

The problem seems to be caused when, after login, the user is redirected back to the page they were on. I've managed to get around it for now by redirecting them to their account page after login, in the block of code that starts with:

        if (sizeof($_SESSION['navigation']->snapshot) > 0) {

Something somewhere seems to be messing up the "snapshot", but I've no idea what could cause that. The website I am having this problem with uses the Zen Lightbox 1.6.4 mod. The other website that doesn't have this problem, doesn't have that mod. I read somewhere that people with that mod sometimes have problems with cookies. Do you by any chance have that lightbox mod installed?

I've seen something similar to this during plugin development (i.e. self-induced) and was able to ultimately work-around the issue by clearing the session cookies for the site. Please note that I said "work-around", not solution!

You can see, without any special debuggers, what's going on in the store by installing the Zen Cart Notifier Trace (http://www.zen-cart.com/downloads.php?do=file&id=1114) and then try logging in. Be sure to go back to your admin once you've captured the set of notifiers and turn the Notifier Trace off (Configuration->Logging) because the file can grow very large very quickly ... especially with the condition you're describing.

The plugin creates a file in your /cache folder named notifier_trace.log and contains a list of all the page-level processing that's transpired.

I had the same problem with one of the errors mentioned at the top of this thread:
[18-Aug-2013 06:25:53 UTC] PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 3715690265 bytes) in /home/xxxxxxx/public_html/includes/functions/html_output.php on line 62
BRAND NEW install of Zen Cart 1.5.1 - no mods - clean database.
What worked for me to get rid of the problem with getting a blank page when trying to log in was to go to Configuration>Sessions>Force Cookie Use and change it to True
Once I did that, no more problems with logging in

Hope this helps someone!

Found and Fixed!

The problem is that when php shuts down global variables might already have been deleted when the default session write and close happens. There doesn't seem to be any synchronization between the two processes. Here are the php bug tickets regarding this:

This has all the pertinant info:
https://bugs.php.net/bug.php?id=54157

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83140#c14601

On request shutdown, PHP does things in the following order:

register_shutdown_function() functions
zend_call_destructors()
zend_deactivate_modules()

zend_call_destructors() goes through the $GLOBALS symbol table and identifies every global variable that holds an object which has a reference count of 1. It removes these globals. It doesn't decrement any reference counts. Any globals which are not objects, or have a reference count greater than 1, are left in the symbol table.

I believe the "fixes" that have worked for people have simply moved the symbol table around enough that the global $db is still active when session_write is called in zencart.

The fix is to set a shutdown function that does a session write close itself:

register_shutdown_function('zc_shutdown');

function zc_shutdown() {
  // other shutdown code as needed
  // write session now
  session_write_close();
}

Then in includes/functions/sessions.php, in _sess_write, change to:

if (!is_object($db)) {
      //error_log('session write with no global db variable! sessions.php .60');
      // https://bugs.php.net/bug.php?id=54157

      // session could be closed with no global variables
      // if so, just exit, nothing we can do
      // workaround is to register shutdown function that saves session
      // and this last call is no-op
      return;

      //PHP 5.2.0 bug workaround ...
//      if (!class_exists('queryFactory')) require('includes/classes/db/' .DB_TYPE . '/query_factory.php');
//      $db = new queryFactory();
//      $db->connect(DB_SERVER, DB_SERVER_USERNAME, DB_SERVER_PASSWORD, DB_DATABASE, USE_PCONNECT, false);
    }

If we come upon a session write where we don't have global variables, it's probably because they've been destroyed. This is OK because we have already done a session write in our shutdown function, so we can ignore this session write. Of course, do not set any session variables after the shutdown function is called.

This has worked in two cases where I had this strange "session write with no global $db" value in php 5.3 and 5.4.

Changes committed to github: https://github.com/zencart/zencart/commit/8f47bc47bdf6c8a189f51d00e26deb80026d2886

I downloaded the github code and saved that version of /includes/functions/sessions.php to my otherwise unmodified ZC v1.5.1 test site running PHP 5.4.21. I've got the replication of this down to a time-consuming couple of steps:

1. Make sure that you are logged out of the store
2. Click Login, then the "Password Forgotten" link. Enter your email address and request a new password.
3. Wait for the 24-minute (I usually waited an hour to be sure) session timeout to expire.
4. From the login page (where you were redirected after confirming the forgotten password), enter your email address and the password you received in the email.
5. You're redirected to the time_out page because the session expired. Enter your email address and new password and press Enter.
6. Experience the whitescreen experience. The log that's created is "memory exhausted" by html_output.php.

lat9:

I downloaded the github code and saved that version of /includes/functions/sessions.php to my otherwise unmodified ZC v1.5.1 test site running PHP 5.4.21. I've got the replication of this down to a time-consuming couple of steps:

2. Make sure that you are logged out of the store

3. Click Login, then the "Password Forgotten" link. Enter your email address and request a new password.

4. Wait for the 24-minute (I usually waited an hour to be sure) session timeout to expire.

5. From the login page (where you were redirected after confirming the forgotten password), enter your email address and the password you received in the email.

6. You're redirected to the time_out page because the session expired. Enter your email address and new password and press Enter.

7. Experience the whitescreen experience. The log that's created is "memory exhausted" by html_output.php.

So, in another thread, one of the ZC knowledgeable suggested the following thread for a memory issue. My apologies if it happens to lead back here or to the same suggested fixes as in here. Trying to provide some input where I've seen a similarity.

http://www.zen-cart.com/showthread.php?207435-php-5-4-fatal-error-Allowed-memory-size-of-83886080-bytes-exhausted

mc12345678:

So, in another thread, one of the ZC knowledgeable suggested the following thread for a memory issue. My apologies if it happens to lead back here or to the same suggested fixes as in here. Trying to provide some input where I've seen a similarity.

http://www.zen-cart.com/showthread.php?207435-php-5-4-fatal-error-Allowed-memory-size-of-83886080-bytes-exhausted
Right, the reason for my post is that the code update to /includes/functions/sessions.php referenced by both this and the post you indicated might correct "part" of the problem, but the 'memory exhausted' issue is still there even with the code update.

The log I received was```
[22-Nov-2013 13:14:55 America/New_York] PHP Fatal error: Allowed memory size of 94371840 bytes exhausted (tried to allocate 746619897 bytes) in xxx/includes/functions/html_output.php on line 62

... the referenced line being the relatively innocuous

  if (defined('SID') && zen_not_null(SID)) {

Can you install Xdebug (http://www.xdebug.org/) on your server? It prints a call stack whenever there is a fatal error so you can see the function path to the crash. If the crash is not in session_write then you might have a different crash issue. I'll see if I can test this too soon.

avibodha:

Can you install Xdebug (http://www.xdebug.org/) on your server? It prints a call stack whenever there is a fatal error so you can see the function path to the crash. If the crash is not in session_write then you might have a different crash issue. I'll see if I can test this too soon.
It's going to be "difficult" to get this installed on my host. I did install it on my localhost (xampp) environment (PHP 5.4.8) on my Windows 7 machine. Going through the same sequence in that environment (my test installation for the failing Linux-hosted store) results in no error, so it's either a PHP version or Linux vs. Windows session-handling issue. In both cases, I used the most recent version of FireFox as the browser.

If it will help, I can PM you a copy of the phpinfo() from the failing hosted environment ...

I also started experiencing same problem after I migrated to Godaddy unlimited shared hosting from another Godaddy hosting. I copied fixed version of "session.php" from github. But problem persist. FYI: My zen cart version is 1.51
Here is error message from Godaddy when I try to login. It stuck on below blank page.
/index.php?main_page=login&action=process

"Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator at [email protected] to inform them of the time this error occurred, and the actions you performed just before this error.
More information about this error may be available in the server error log.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
"
Here is Zen cart log.

[26-Nov-2013 01:24:40 UTC] PHP Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 693694233 bytes) in /home/xxxxx/public_html/includes/functions/html_output.php on line 62
"
Is there any other fix?

DrByte:

Changes committed to github: https://github.com/zencart/zencart/commit/8f47bc47bdf6c8a189f51d00e26deb80026d2886