Upon further inspection, it is clear that shutdown_memory_manager is called before php_apache_request_shutdown. This, it seems, hails back from the change that caused cleanup to happen before the connection closed, which may or may not be related to the memory management changes. This causes the Zend engine to deallocate all my nice pointers.
php_apache_request_shutdown is run as an apache cleanup routine. This is good design, but in main.c in php_request_shutdown, the PHP code as it exists when the process is running is destroyed. This long before the connection is shut down, and in turn long before php_apache_request_shutdown is run. Thus any attempt to move php_call_shutdown_functions any lower in the execution order of php_request_shutdown results in a segmentation fault. This was what I did originally to test for an execution location where the connection was closed but PHP was still intact. It seems, as I suspected, that there is no place where the connection is closed and PHP code still exists. Back to the solution proposed, I've put a test around the sapi_close call which means that it will only be called if there are registered apache shutdown functions. Will this placate you? It will thus only break keep-alive if there are offline functions to be run. If this is still unacceptable, the php_request_shutdown may need to be redesigned, and thus, I fear, all of SAPI. Joseph > -----Original Message----- > From: Joseph Tate [mailto:[EMAIL PROTECTED]] > Sent: Monday, December 30, 2002 2:55 PM > Subject: [PHP-DEV] RE: [PATCH]apache_register_shutdown_function final > version > > > That's no good. If I remove the sapi_close stuff, and try to execute the > shutdown functions in php_apache_request_shutdown() all I get is stuff in > the error log listing the "leaked" memory. The requested > function does not > get executed. > > Joseph -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
