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

gsmsalers, that was the exact question I wanted to ask zen-cart experts.

The only side effect I see of $add_session_id=false is if you have a different host for your SSL connection. If they are different, and the user's cookies don't work (a rare occurence), the session would not be carried over to the ssl connection. Otherwise it won't have any effect.

It would be good to find out where this problem is coming from. Can you install xDebug on your server? That will give a stack trace for this error that would help to debug the cause.

Avibodha, thank you for your info. At least your answer make me feel much better. As for xdebug, I haven't install it and may give it a shot when I have time.

Back again on this.:( I inserted a write to the error log in /includes/functions/html_output.php, just before the SID-related failure and the debug_backtrace showed index.php requiring /includes/modules/pages/login/header_php.php which subsequently called the zen_redirect function. FWIW, I broke up the combined statement like this:

// Add the session ID when moving from different HTTP and HTTPS servers, or when SID is defined
    if ( ($add_session_id == true) && ($session_started == true) && (SESSION_FORCE_COOKIE_USE == 'False') ) {
      $val1 = defined ('SID');
      $val2 = $val1 && SID != '';

... the out-of-memory error is occurring on the highlighted statement. I'd love to get xdebug installed to see what's up, but the (non-)technical support staff at 1&1 are hard enough to communicate with on simple issues. No problems logging into the admin, but I'll be :censored: if I can get logged into the store-side.

Again, I've got the v1.5.2/v1.6.0 changes to the sessions handling installed on an otherwise clean v1.5.1 fileset.

lat9:

... Again, I've got the v1.5.2/v1.6.0 changes to the sessions handling installed on an otherwise clean v1.5.1 fileset.
I went back to (actually) look at what I had installed -- as opposed to what I thought was installed -- and it turns out that I'd installed a couple of observer-class plugins (notifier trace, report all errors) to try to figure out what was up. I disabled (via file-extension rename) the load of these plugins and I'm able to log in. Add them back, no login. Rename one -- doesn't matter which -- login. Hmm.:dontgetit

I've also got the ZC 1.5.2-RC2 version of /includes/classes/class.base.php loaded. The site is running PHP 5.4.25.

I'm just wondering if this has anything to do with the pass-by-reference deprecation in PHP 5.4, since the attach function of the base class is passing a reference to the observer for later use:

  function attach(&$observer, $eventIDArray) {
    foreach($eventIDArray as $eventID) {
      $nameHash = md5(get_class($observer).$eventID);
      base::setStaticObserver($nameHash, array('obs'=>&$observer, 'eventID'=>$eventID));
    }
  }

The thing deprecated in 5.4 was forcing a pass-by-reference in a function call. http://www.php.net/manual/en/language.references.pass.php

The attach function is only assigning a reference to an object ($observer) to an array item. So I don't think this would cause a fatal error by itself. I don't know what the cause of the the problem you're seeing.

From what I've seen, the cause of these crashes is never actually in html_output, something has been corrupted way before that. If you have any zen_redirect, try putting session_write_close() before them. I think you need more access to your server to do much more debugging. (xdebug, etc).

You could try with an empty observer class and see if that works, then add back up code till it crashes again.

Thanks, avibodha. I'm just grasping at straws at this point. I'll post back if I find anything.

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;
  }

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.

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

lat9:

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;
}

lat9:

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

avibodha:

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.
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.

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.

avibodha:

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

stellarweb:

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!

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.

lat9:

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

gsmsalers:

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?

kagaroo:

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([B]constant([/B][B]'[/B]SID[B]'[/B][B])[/B])) {
        $sid = [B]constant([/B][B]'[/B]SID[B]'[/B][B])[/B];

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%29; enabling error-reporting for "Notice" type errors would have shown it up!

DrByte:

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([B]constant([/B][B]'[/B]SID[B]'[/B][B])[/B])) {
$sid = [B]constant([/B][B]'[/B]SID[B]'[/B][B])[/B];

> 
> 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.:smile:

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

DrByte:

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([B]constant([/B][B]'[/B]SID[B]'[/B][B])[/B])) {
$sid = [B]constant([/B][B]'[/B]SID[B]'[/B][B])[/B];

> 
> 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.

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

torvista:

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.