Bug #15209 Updated: Under Apache, register_shutdown_function() broke between 4.0.x to 4.1.x

From: Date: Fri, 07 Jun 2002 15:38:49 +0000
Subject: Bug #15209 Updated: Under Apache, register_shutdown_function() broke between 4.0.x to 4.1.x
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-9767@lists.php.net to get a copy of this message
ID: 15209 Updated by: zeev@php.net Reported By: priebe@mi-corporation.com Status: Open Bug Type: Output Control Operating System: RH Linux 7.2 PHP Version: 4.1.x - 4.2.1 New Comment: This should be discussed. Generally, it's not obvious that shutdown functions should be executed after the connection shuts down. It may very well be used to print out information, which obviously cannot be done if it's done after the user disconnects. I believe that getting this behavior to work is only possible under Apache. With most (all?) other server APIs, it's only possible to do things while the user is still connected. So, if we want consistency across web server, the existing behavior is the desired one. Previous Comments: ------------------------------------------------------------------------ [2002-06-03 15:59:29] jtate@php.net This bug still exists in 4.2.1 version. If it's reproduced 6/6 times on different platforms with an average score of 4.9, it's pretty important if not critical. Here's a sample script: <?PHP function foo () { sleep (10); print "foo<BR>\n"; } print "pre shutdown<BR>\n"; register_shutdown_function (foo); print "shutting down<BR>\n"; ?> This should return immediately printing pre shutdown shutting down but instead waits ten seconds then prints pre shutdown shutting down foo ------------------------------------------------------------------------ [2002-06-03 09:46:38] priebe@mi-corporation.com IIRC, somebody from the PHP team set the "Critical" flag after confirming its existence. I've come to the conclusion that register_shutdown_function() is one of the least-exercised portions of the PHP core, based on the fact that the docs and online comments have never mentioned the fact that it never worked under anything but Apache+*nix. Seems to me that the nature of the bug _is_ critical, since any application that depends on register_shutdown_function() will fail horribly if the call does not work. At any rate, we will test. Thanks. ------------------------------------------------------------------------ [2002-06-03 09:38:28] mfischer@php.net Can't be critical, no one else reported this yet. Please test with latest Apache/PHP and see if this problem still exists (regardless of the source in sapi_apache.c) ------------------------------------------------------------------------ [2002-01-24 13:01:19] priebe@mi-corporation.com Under Apache 1.3.20 and PHP 4.1.1, register_shutdown_function() will run the specified function, but it will not close the connection to the client. I have isolated the problem to sapi/apache/sapi_apache.c. In apache_php_module_main(), php_request_shutdown() is called. When called from this location, the connection is not shut down. However, if you comment this call out (along with the AP(in_request) = 0), it will be called from php_apache_request_shutdown() instead. When called from this function, php_request_shutdown() operates as expected. I do not understand enough about why the changes were made from 4.0.x to 4.1.x. I also have not fully tested this change to see if there are undesirable side effects. I was hoping that someone more familiar with PHP internals would look at it and have an "A-HA" moment. Here is a patch (hope this survives the cut-and-paste): --- php-4.1.1/sapi/apache/sapi_apache.c Sat Aug 4 21:42:45 2001 +++ ../php-4.1.1-changed/php-4.1.1/sapi/apache/sapi_apache.c Thu Jan 24 12:08:40 2002 @@ -89,13 +89,13 @@ (void) php_execute_script(&file_handle TSRMLS_CC); } - +/* AP(in_request) = 0; zend_try { php_request_shutdown(NULL); } zend_end_try(); - +*/ return (OK); } /* }}} */ ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=15209&edit=1

« previous php.bugs (#9767) next »