php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #21040 max_execution_time ignored
Submitted: 2002-12-16 03:24 UTC Modified: 2003-02-27 10:53 UTC
From: alain at cscoms dot net Assigned:
Status: Not a bug Package: Apache2 related
PHP Version: 4.4.0-dev OS: Solaris x86 2.7
Private report: No CVE-ID: None
View Add Comment Developer Edit
 [2002-12-16 03:24 UTC] alain at cscoms dot net 
I have max_execution_time set to 30 and safe_mode set to On in php.ini. The phpinfo() page shows them as such.
When PHP 4.3.0RC3 is compiled as a module for Apache 2.0.43, a script that loops is never stopped e.g.:

loop.php:

cat loop.php 
<?
while ( 1 ) {
}
?>

will loop forever. I have tested that max_execution_time value is correct by having a script use ini_get to get it and display it.

PHP configured as:
./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql=/usr/local --enable-memory-limit=yes --enable-track-vars --enable-debug=no --enable-sockets
Apache configured as:
CFLAGS="-DFD_SETSIZE=8128" ./configure --enable-so --enable-ssl --enable-include --enable-cgi --enable-rewrite --enable-status --enable-expires --enable-info --with-egd=/var/run/egd-pool --with-mpm=worker

More checks done:

PHP 4.3.0RC3 configured for Apache 1.3.26 static works normally.

Same, with Apache 2.0.43 configured to use prefork (non-threaded) model instead of worker: works also.

So it seems to be related to the Apache 2 threaded stuff.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-12-16 03:27 UTC] derick@php.net 
Recategorize.

Can you also try it with the latest CVS version (HEAD) (you may find the development snapshot at http://snaps.php.net
 [2002-12-16 04:47 UTC] alain at cscoms dot net 
Just tried with php4-200212160830 (4.4.0-dev): same, the script never exits.
I'm compiling this on Solaris 2.7/SPARC and FreeBSD 4.5 to see how much O/S & platform specific this problem is.

I've added a
zend_printf("zend_timeout<BR>\n");
to zend_timeout() (Zend/zend_execute_API.c). I can see the message in the browser when timeout works (like when running in Apache 1.3) but not when it doesn't (although my loop.php script now exits after a huge for loop so that I can see the page output). So I presume that the signal triggered by setittimer in zend_set_timeout() is never delivered.

Thanks for the impressively fast reply!
 [2002-12-16 05:08 UTC] sniper@php.net 
reopened..(please don't add comments to your own bug report, use the 'Edit Submission' and change the status to open when you give feedback.)
 [2002-12-16 05:09 UTC] alain at cscoms dot net 
Just out of curiosity, and admittedly not quite understanding what I was doing, I have tried changing the zend_set_timeout code to use SIGALRM instead of SIGPROF and thus pass ITIMER_REAL to setitimer instead of ITIMER_PROF

Guess what? It works now.

I understand that this can have nasty side effects. I was just wondering why SIGPROF was being used and if this could be the reason. The setitimer man page on Solaris says a lot of things about using it in MT environment which I don't quite catch :-)
 [2002-12-16 05:12 UTC] alain at cscoms dot net 
[oops, posted this as "add comment" because I hadn't read the direction to use "edit submission" instead yet --sorry]

Just out of curiosity, and admittedly not quite understanding what I was doing, I have tried changing the zend_set_timeout code to use SIGALRM instead of SIGPROF and thus pass ITIMER_REAL to setitimer instead of ITIMER_PROF

Guess what? It works now.

I understand that this can have nasty side effects. I was just wondering why SIGPROF was being used and if this could be the reason. The setitimer man page on Solaris says a lot of things about using it in MT environment which I don't quite catch :-)
 [2002-12-16 06:44 UTC] alain at cscoms dot net 
Works on FreeBSD 4.x (with unmodified PHP source).
So it's kind of Solaris-specific (will test on Sparc)
 [2002-12-16 10:51 UTC] iliaa@php.net 
Sounds like some is taking over the handler for the SIGPROF and it never gets to PHP. Besides PHP, what modules/extensions do you have enabled in your Apache?
 [2002-12-16 20:27 UTC] alain at cscoms dot net 
No module/extension besides the ones shown in the configure command line above (rewrite, expires, status, info). The configuration of the FreeBSD test box is a copy of this one, and it works. Could it be that the threads library itself is either taking over SIGPROF of blocking it somehow?
I'm considering building Apache with an alternate threads library to see what happens.
 [2002-12-17 06:20 UTC] alain at cscoms dot net 
- tested on Solaris 2.7/SPARC: fails too
- gave up trying to build Apache 2.0.43 with an alternate threads library: can't get MIT pthreads to build
- Sunsolve mentions bug causing SIGPROF not to be delivered
in certain cases, but this only concerns the "alternate" threads library on Solaris 2.8. Nothing related to 2.7. I've tried to install the latest Solaris 2.7 libthreads.so.1 patch: doesn't solve the problem
 [2003-02-27 10:53 UTC] iliaa@php.net 
Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

Sounds like a bug with Sun's threading library and not a PHP issue. Unless some indication can be found that this is the result of inproper signal handling by PHP this bug report is bogus (not a PHP issue).
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri May 24 19:01:29 2024 UTC