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

[lat9]

avibodha, it came from some code that I'm developing. I'm guessing that since the constant i was not defined, it was treated as 0 so the for-loop was, essentially, infinite thus resulting in the out-of-memory condition.

I'll certainly post my finding, but I'm already anticipating the result ... won't fix.

[wilt]

Hi,

Sorry it's taken so long to address this. Totally agree with your fix. Expect to see it rolled into 152/1.6 shortly

Not that this change made any difference in my situation, but shouldn't the static observer value be initialized on first use? The first time an attach request is received, the value's NULL:

  function setStaticObserver($element, $value)
  {
    $observer =  & base::getStaticObserver();
    if (!is_array($observer)) {
      $observer = array ();
    }
    $observer[$element] = $value;
  }

[DrByte]

OK, here's a weird one. I got the "memory exhausted" error running in a localhost environment and thought "aha!" now I can get that debug package loaded! Looking at the line that resulted in the error

$height_inches = array ( array ( 'id' => '-1', 'text' => TEXT_PLEASE_CHOOSE ) );
for ($i = 0; i < 12; $i++) {
  $height_inches[] = array ( 'id' => $i, 'text' => $i );
}

I noticed that the comparison portion was missing its $

$height_inches = array ( array ( 'id' => '-1', 'text' => TEXT_PLEASE_CHOOSE ) );
for ($i = 0; $i < 12; $i++) {
  $height_inches[] = array ( 'id' => $i, 'text' => $i );
}

Why the heck would that have triggered an out-of-memory condition? Shouldn't a parse error have been asserted instead? PHP 5.4.8

Good catch!
If there is no $ in front of a variable, php treats it as a defined constant.
What page is this from?
I have no idea how a compare to 12 would work, but obviously it was less and kept adding to the array till you ran out of memory. Could you post this to bug fixes?

I would have expected that this would give you a message like "tried to allocate (small number) of bytes and failed", instead of trying to allocate random huge number of bytes like the other errors.

avibodha, it came from some code that I'm developing. I'm guessing that since the constant i was not defined, it was treated as 0 so the for-loop was, essentially, infinite thus resulting in the out-of-memory condition.

I'll certainly post my finding, but I'm already anticipating the result ... won't fix.

1. As lat9 posted, it would run out of memory because the loop would never complete, since i is treated as a constant (and since uninitialized its value would evaluate to 0 or 1), and never increment to 12 or more. So the loop becomes endless.

2. No point filing it as a ZC bug report, since that code doesn't come from Zen Cart core code. There is no mention of "height_inches" anywhere in Zen Cart.

[DrByte]

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

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!

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.

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)) {

I also started experiencing same problem after I migrated to Godaddy "Ultimate" 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?

Just fresh install zc 1.51 version on my server and test as frank18 suggested. Yes, no problem, I can log in without any problem.

For my site, it was originally for the zc 1.38 and recently upgraded to zc 1.51. It was running smoothly on php 5.2 or 5.3. but not on php5.4.

When switch to php5.4, there two files seems to have problem when customers try to log in.
includes/functions/html_output.php on line 77
includes/classes/seo.url.php on line 215

Both line has the same code nearby.

    if ( ($add_session_id == true) && ($session_started == true) && (SESSION_FORCE_COOKIE_USE == 'False') ) {
      if (defined('SID') && zen_not_null(SID)) {
        $sid = SID;

I have ultimate seo url module installed. But I still get the same error when I disable seo module.

I've been able to replicate the problem. PHP 5.4.21
It does appear to be something very odd with whatever PHP is doing in the background regarding the predefined SID constant.
Making the following change to lines 62-63 seems to bypass the problem and appears to have stopped triggering the PHP out-of-memory condition:

      if (defined('SID') && zen_not_null(constant('SID'))) {
        $sid = constant('SID');

I'd be very interested in hearing your results after applying this change.

[lat9]

avibodha, it came from some code that I'm developing. I'm guessing that since the constant i was not defined, it was treated as 0 so the for-loop was, essentially, infinite thus resulting in the out-of-memory condition.

I'll certainly post my finding, but I'm already anticipating the result ... won't fix.

Found this report as a duplicate (https://bugs.php.net/bug.php?id=50331&edit=2); enabling error-reporting for "Notice" type errors would have shown it up!

[lat9]

I've been able to replicate the problem. PHP 5.4.21
It does appear to be something very odd with whatever PHP is doing in the background regarding the predefined SID constant.
Making the following change to lines 62-63 seems to bypass the problem and appears to have stopped triggering the PHP out-of-memory condition:

      if (defined('SID') && zen_not_null(constant('SID'))) {
        $sid = constant('SID');

I'd be very interested in hearing your results after applying this change.

Most excellent, DrByte! I'll apply those changes to the test-site that was experiencing those issues and let you know! Thanks for looking into this, I was starting to think that it was solely an issue with good ol' 1&1.

[lat9]

Most excellent, DrByte! I'll apply those changes to the test-site that was experiencing those issues and let you know! Thanks for looking into this, I was starting to think that it was solely an issue with good ol' 1&1.

Woo-hoo! I went to my problematic test sub-domain and attempted to login, receiving the OOM error. FTP'd up the proposed changes, clicked Refresh ... and I successfully logged in. Logged out, logged in again.

I'll keep an eye on it, but it looks like (as always) you hit the nail on the head, DrByte!

[buildingblocks]

I've been able to replicate the problem. PHP 5.4.21
It does appear to be something very odd with whatever PHP is doing in the background regarding the predefined SID constant.
Making the following change to lines 62-63 seems to bypass the problem and appears to have stopped triggering the PHP out-of-memory condition:

      if (defined('SID') && zen_not_null(constant('SID'))) {
        $sid = constant('SID');

I'd be very interested in hearing your results after applying this change.

DrByte

your fix worked for me with the same out of memory issue. zen cart 1.5.1 php 5.4.28. At the same time the error was also being generated using the ultimate seo url mod 2.212. The fix worked for the file /includes/classes/seo.url.php too. Thanks for posting the fix.

[torvista]

I note the change
$sid = constant('SID');
has not been incorporated into 1.53 and the corresponding section in 1.6 has changed.

[lat9]

I note the change
$sid = constant('SID');
has not been incorporated into 1.53 and the corresponding section in 1.6 has changed.

... but only in the /admin/includes/functions/html_output.php; the store-side function does have the change incorporated.