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

[kagaroo]

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

[avibodha]

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.

[kagaroo]

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.

[lat9]

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

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

[avibodha]

The thing deprecated in 5.4 was forcing a pass-by-reference in a function call. http://www.php.net/manual/en/languag...ences.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.

[lat9]

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

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