Maximum execution time of 120 seconds exceeded when viewing Whos Online in my admin

Hi,
Can anyone help me to resolve this issue:

Fatal error: Maximum execution time of 120 seconds exceeded in /home/vikjffmw/public_html/admin/whos_online.php on line 416

I get this shown at the top of the page when I look to see who is online within the admin area of my site.

Does anyone know how I can fix this at all?

Thanks,
Adam.

Adds:

Hi,
Can anyone help me to resolve this issue:

Fatal error: Maximum execution time of 120 seconds exceeded in /home/vikjffmw/public_html/admin/whos_online.php on line 416

I get this shown at the top of the page when I look to see who is online within the admin area of my site.

Does anyone know how I can fix this at all?

Thanks,
Adam.

Any ideas on this at all?
Need some help.....

Adds:

Hi,
Can anyone help me to resolve this issue:

Fatal error: Maximum execution time of 120 seconds exceeded in /home/vikjffmw/public_html/admin/whos_online.php on line 416

I get this shown at the top of the page when I look to see who is online within the admin area of my site.

Does anyone know how I can fix this at all?

Thanks,
Adam.

Im getting this error also. Using version 1.3.7

Anyone?

I get it with 1.3.7 and 1.3.8a

SO it may be the version of mysql and PHP, likely php ?

mysql-server-5.0.51
php5-core-5.2.5p1

About how many people are on your site?

Have you had problems in the past or is this new?

less than 10, just bots and guests...
on the oepnbsd server w/ mysql-server-5.0.51 php5-core-5.2.5p1

It may have been lurking, I don't normally look,
but I had moved to a new version of openbsd, and was using
systat vmstat
to watch, and saw a mem hog, and found this...

I have a old test zencart 1.3.6 on an older server that is php5.1.4 and mysql-server-5.0.24a
but it had less than 2 guests, and I don't recall a whos_online issue with it.
nor see a runaway max exec on it.

You're not using any add-ons for the whos_online are you?

nope,

The stock file.

the unix "top" shows that an httpd, web services is maxing out the resources
when I click on whos online, and I am not getting mysql_log slow for whos online. thats why I thought it may be php version/setting related...
apologies above, not mem hog, CPU hog I meant to say.

I guess in my spare time I need to look closer at what php activity is going on in admin/whos_online.php and check the php.ini settings

If you find something do let us know ...

I am leaning towards something with the php 5.2.5 version as there have been other odd issues on that version from reading through the php site ... :unsure:

Linda,

Just a thought but in whos_online.php (ZC v1.3.8) at line 403 it says

$start_cart = strpos($session_data, 'cart|O');

...then at line 409...

for ($i=$start_cart; $i<$length; $i++) {

Before the 'for' statement there is no check to ensure that $start_cart is a valid number. strpos() will return something equal to false if the string isn't found. If the session information is fubar then it may be causing an infinite loop.

Regards,
Christian.

BINGO YOU GOT IT

I just put this hack in front of line 409

settype($start_cart,"integer");

(like what you would do to variables to prevent sql injections..._

You'd probably find a better FIX,
but that seemed to work for now.

!!!

NEED to get this bug reported... properly

:smile:

CJPinder - you NAILED IT

:smartalec:

I put this line just before 409 in admin/whos_online.php

settype($start_cart,"integer");

That got rid of the cpu going bannanas

guess php 5.2.5 will let you loop untill time out.... maybe.
:clap:

need to report this for next update.

ppruett:

CJPinder - you NAILED IT
need to report this for next update.

sorry about double posts...

anyways, I put a thread under Bugs:

http://www.zen-cart.com/forum/showthread.php?t=88301

Hmmm... that means that...

$start_cart = strpos($session_data, 'cart|O');
```...is settting $start_cart to false. Now strictly speaking there should be a check for this before using the value of $start_cart, however in theory $start_cart should never end up being false unless something has gone wrong elsewhere. It is possible that PHP 5.2 is serializing the session data differently but that seems unlikely, it could also be that session data has become corrupted.

It might also be the check for PHP version that occurs. It would be worth trying replacing this code...(starting a line 395)
```php
      if (PHP_VERSION < 4) {
        $start_id = strpos($session_data, 'customer_id[==]s');
        $start_cart = strpos($session_data, 'cart[==]o');
        $start_currency = strpos($session_data, 'currency[==]s');
        $start_country = strpos($session_data, 'customer_country_id[==]s');
        $start_zone = strpos($session_data, 'customer_zone_id[==]s');
      } else {
        $start_id = strpos($session_data, 'customer_id|s');
        $start_cart = strpos($session_data, 'cart|O');
        $start_currency = strpos($session_data, 'currency|s');
        $start_country = strpos($session_data, 'customer_country_id|s');
        $start_zone = strpos($session_data, 'customer_zone_id|s');
      }
```...with just...
```php
      $start_id = strpos($session_data, 'customer_id|s');
      $start_cart = strpos($session_data, 'cart|O');
      $start_currency = strpos($session_data, 'currency|s');
      $start_country = strpos($session_data, 'customer_country_id|s');
      $start_zone = strpos($session_data, 'customer_zone_id|s');
```...because the check against PHP_VERSION  might be failing and no one uses PHP 3 anymore anyway.

Regards,
Christian.

nope,

I took my settype out, then tried what you suggested,
nope, got the timeout again,
so put back in settype function.
but left the php3 condition out, as you say, don't use php3 anyways...

I tried a simple print line;
print("<p>" . PHP_VERSION . "</p>");

and it printed 5.2.5
so it is recognizing the version.... so maybe 5.2.5 > 4

was not aware the > ignored the periods quite like that.

and whatever is $start_cart does not print so reckon that settype integer is zero....

so we may have a gremlin that has more far reaching effects, IF, $session_data elswere
has similar mangling...

or further up the page in the script where $session_data is generated and manipulated it may have mangled?

hmmm..there must be something odd about the session data then. Any chance you could try putting the following at line 408 (just before the 'for' statement and before you settype it to integer)...

if ($start_cart === false)
    echo "<br /><pre>".$session_data."</pre><br />";

...and then post one of the the outputs here between code tags. I'm not sure how big it will be and there might be personal data in there that will need blanking out.

Regards,
Christian.

per request
session data example on admin/whos_online.php

1Kd4yPEyHcqTmcqrR61TTKMtxY3PDquNXxaxemxPm3w95H7MMBEtR3gzZVvrcsugM-TJfev1RnRRHhsQx8wnTRD0wypHCbJDTOnWwjFvq8kXZEf0SdpsA3-t8Xu4A45wzKHsZyeEvnYuFR1cy1eS6x1Vcwm7lUkR3gKK7DMLtg1mT67lueHlHLVxPgG8n-Fmr-bIfWm5F83nuLKO5-7KVojs7hIM0VI6wOEjpTE0XVDKQJBOcso7Cvdiu7gBqtY1kVsIHB58OOTRcbL-MAn1isUHC-WvKv73NuYoS4cyzkTmUAoR8zsFzum5Dwdz0AlyHElzkotcdZD-wI9BO--09UAKBXxfBd4CgVYQe1IwuyAW0GX2EDP8qTZBz5t4niPVQXOJmokNJGHTLtYdD3ED2LHNLXlrBKix2DZxz69ngOVPYrA7OJlmURRkC9iJePCEsFpul_Hoh1V9OqzbxlQVfa9q4knIQwezgZMBBSm6VJgJLBbzFdBegP7Lv5zh5EPsuuXJtJWaVi0Ra9WW5c_r-K8mhq0eKBEM5XRz1wIvFugfQD0he2EjHh4IRtm5z017G_9FRiDOPpMohF5Ak4y9qH1HSsV0KcxtVAUB1mYAwS73bV1jqAgZufZ9IrH8LcmhDFakBoMJq7koUIulTj9hcCBaEbnraycn9XrmqYCzcEgD6tx1P0lEICTylfPxPo9mbHnJph-BOVy1CbL4wuHpZQZ9iD6u_cn3iVqyEbcmHT-FREvW6rqZbMrKiRe2BLSuDQK-WsiNTeiRuGDnfSRL3kwtOdF_HlpTuISzR8S8kD-f6dWmoUoDAzyPrjRM4TepC8EudCFEU7M5EKGOPXYO2L7cBDC6g-6Mwxjw5l0XqxHyCRiK3AA6Y4NFWklGiWGXaklYKvfvFVY71autNfNpKQ5i44vwIGTmHZ6K1QHg_EiU9Z_fANMJEL0HNsMEPxIWyCDjHxyDAMtGKJTyzKgx-cUuRIjvEY3t3Exa8LWw7he-C6IWCYz8Lb4D6XhnMvWL77OM3lLM1qzOe8xazjsqQJw3zLGFSu9JUFDtd1WMqMKhP5xoPcZuck1twR_Rx59CkZFzeIReO-G-aMJqlJRFFQ..

BTW, putting that echo of $session_data
causes a change to the output of the page, making the whos online table extremely wider...

ppruett:

per request
session data example on admin/whos_online.php
Thanks for that. It is starting to make a bit more sense now. Looks as if your PHP installation has a secure session handler installed. This means that session data is encrypted then base64 encoded before being stored. Zen Cart is a bit naughty and tries to read customers' session data directly to show you their cart contents. With secure session handling it breaks. I'll see if I can think of a way around it.

Regards,
Christian.

CJPinder:

Looks as if your PHP installation has a secure session handler installed. This means that session data is encrypted then base64 encoded before being stored.
Having thought some more, I could be wrong about the encryption bit, it could well be just straight binary that is base64 encoded.

Could you login to Zen Cart admin then do Tools -> Server/Version Info. From there tell me what session.serialize_handler is set to.

Many thanks,
Christian.

session.serialize_handler  php  php