php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22747 Getting maximum execution timeout errors on lines which shouldnt be doing so
Submitted: 2003-03-17 10:06 UTC Modified: 2003-07-20 10:35 UTC
Votes:9
Avg. Score:4.9 ± 0.3
Reproduced:3 of 3 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (33.3%)
From: carl at voodoomedia dot co dot uk Assigned:
Status: No Feedback Package: Session related
PHP Version: 4.3.2-RC OS: Windows 2000 SP3
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: carl at voodoomedia dot co dot uk
New email:
PHP Version: OS:

 

 [2003-03-17 10:06 UTC] carl at voodoomedia dot co dot uk
I'm having some very strange issues with maximum execution timeouts. I've set them to 45 seconds in my php.ini and it's picking these up fine, but what I am getting is errors telling there that there are timeouts in lines which I really would not expect any timesout to happen. for example

[17-Mar-2003 16:00:17] PHP Fatal error:  Maximum execution time of 45 seconds exceeded in e:\www\include\inc_sessiondata.php on line 13

and ine 13 in this file is

session_register("tmp_username");

only thing before this line is a session_start();

so I cannot see how a 45 second timeout could happen there?

I've also had a timeout when just doing includes as below

include_once('include\inc_showheader.php');

showheader.php just includes HTML and only PHP code in there are simple echo's

So i'm confused as to why a timeout would happen with the above situations.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-03-17 15:26 UTC] carl at voodoomedia dot co dot uk
Thanks for that, I tried the latest windows snapshot as you suggested but it did not fix the problem, latest one was a timeout on this line!!!

echo '</td></tr>';
 [2003-03-17 19:49 UTC] sniper@php.net
I can't reproduce this...what have you changed in your
php.ini compared to the php.ini-dist ??

Can you provide a complete but short example of code
that can be used to reproduce this?


 [2003-03-18 09:23 UTC] iliaa@php.net
Disable the ZendOptimizer and try the code again.
 [2003-03-18 09:32 UTC] carl at voodoomedia dot co dot uk
It happens without zend installed, I installed that last night in the hope that it would solve the time outs by speeding things up :(((
 [2003-03-18 11:38 UTC] sniper@php.net
You're doing something wrong, ask support questions on the mailing lists.


 [2003-03-25 05:51 UTC] carl at voodoomedia dot co dot uk
I'm afraid that "You're doing something wrong" just isn't an acceptable answer.

It's a problem with PHP's session handler or serializer for sure. I can replicate it by using this script

<?php
     session_start();
     if (!isset($_SESSION['tempVal'])) $_SESSION['tempVal'] = 0;
     $_SESSION['tempVal']++;     
     echo 'session val is now '.$_SESSION['tempVal'].'<BR>';
     echo '<A HREF="sesstest.php">click here to reload</A>
?>

If I call that page from an automated page refresh script that I have at some point within an hour I will get 

[25-Mar-2003 11:37:27] PHP Fatal error:  Maximum execution time of 40 seconds exceeded in e:\www\sesstest.php on line 2.
 [2003-03-25 06:46 UTC] sniper@php.net
What webserver is used? How is PHP configured in it?
Are you using CGI binary or a module?
What is the diff -u between the php.ini-dist file and your
php.ini ? 


 [2003-03-25 07:07 UTC] carl at voodoomedia dot co dot uk
Hi there,

I'm using Apache 1.3.27 on a windows 2000 SP3 machine, dual P3 1.6ghz processors and 1.5GB RAM

PHP is loading as an apache module and i've tried 4.3.1 and 4.3.2 latest cvs binaries.


the differences in my ini from php-dist are

short_open_tags = Off
precision = 14
zlib_output_compression = on (but only did this last night wsa off until then)
allow_call_time_pass_reference = off
max_execution_time = 40
error_reporting = E_ALL
display_errors = Off
log_errors = On
ignore_repeated_errors = on
error_log = e:\php.log
register_argc_argv = off
magic_quotes_runtime = on
include_path = e:\www\
doc_root = e:\www\
extensions_dir = c:\php\extensions
upload_max_file_size=4M
default_socket_timeout=30
SMTP=[ip to local smtp server]
session_save_path = c:\php\sessions
session.gc_dividend = 1000
session.bug_compat_warn = 0 (makes no difference, still see em)



Thanks
 [2003-07-13 00:09 UTC] sniper@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

And update the version if this still happens to you (when using the snapshot). And make sure you delete ALL old remains of PHP related files first before installing the snapshot!!

 [2003-07-20 10:35 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 [2003-07-24 10:09 UTC] siggi at junesystems dot com
I'm having similar problems with sessions. On a dual Xeon 2,4 GHZ running RedHat 9, Apache 1.3.27 and PHP 4.3.2 module, session_start() sometimes takes milliseconds and other times it takes up to 13 seconds to complete.

I've timed it with the following code:
<?
$start = microtime();
session_start();
$stop = microtime();
echo $stop - $start;
?>

The results are not reproducable in small script containing only the previous code, but happen in a large application and it seems to happen only when data is Posted. No code is run before the session is started, so I'm at a loss what might be causing the problems.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 18 05:01:28 2024 UTC