Edit report at http://bugs.php.net/bug.php?id=47412&edit=1

 ID:               47412
 User updated by:  tser at deltacontrols dot com
 Reported by:      tser at deltacontrols dot com
 Summary:          PHP_MSHUTDOWN_FUNCTION not being called under FastCGI
-Status:           Feedback
+Status:           Open
 Type:             Bug
 Package:          CGI related
 Operating System: win32 only - Vista
 PHP Version:      5.2.9RC2
 Assigned To:      pajoye

 New Comment:

Using Vista64 IIS7 with the update (KB980363).



1. Setup PHP FactCGI in IIS. Everything default.



2. Open C:\Windows\System32\inetsrv\config\applicationHost.config

Edit the <fastCgi> section and add signalBeforeTerminateSeconds="30"



<fastCgi>

            <application fullPath="C:\Program Files
(x86)\PHP\php-cgi.exe" maxInstances="2" idleTimeout="30001"
activityTimeout="3000" instanceMaxRequests="10000"
signalBeforeTerminateSeconds="30">

                <environmentVariables>

                    <environmentVariable name="PHP_FCGI_MAX_REQUESTS"
value="10000" />

                    <environmentVariable name="PHPRC" value="C:\Program
Files (x86)\PHP\" />

                </environmentVariables>

            </application>

</fastCgi>



3. Create a test.php with <?phpinfo();?>. Browse it.

4. Attach debugger to php-cgi.exe process (with debug symbol).

5. Put a breakpoint in sapi/cgi/fastcgi.c (after WaitForSingleObject)

static DWORD WINAPI fcgi_shutdown_thread(LPVOID arg)

{

        HANDLE shutdown_event = (HANDLE) arg;

        WaitForSingleObject(shutdown_event, INFINITE);

        in_shutdown = 1; <--------------breakpoint here

        return 0;

}

6. Put a break point in ext/date/php_date.c

PHP_MSHUTDOWN_FUNCTION(date)

{

        UNREGISTER_INI_ENTRIES();



        return SUCCESS; <----------------breakpoint here

}

7. Open a command prompt and do a iisreset.



Notice that the breakpoint in fcgi_shutdown_thread will get hit but the
PHP_MSHUTDOWN_FUNCTION(date) function is not being called.





Before the IIS updates, FastCGI module always force kill php-cgi.exe,
make it impossible for php-cgi.exe to properly call
PHP_MSHUTDOWN_FUNCTION for each extension. 

With the new setting signalBeforeTerminateSeconds,
"_FCGI_SHUTDOWN_EVENT_" will be triggered to give php-cgi.exe a change
to do proper cleanup. There are actually code in fastcgi.c (PHP) to wait
for that event. However, it still does not properly call
PHP_MSHUTDOWN_FUNCTION for all the loaded extension.


Previous Comments:
------------------------------------------------------------------------
[2010-05-13 21:03:18] paj...@php.net

Please post the relevant information here ( > feedback again).

------------------------------------------------------------------------
[2010-05-13 20:27:26] tser at deltacontrols dot com

I cannot re-open the bug.

There are more info on handling of SignalBeforeTerminateSeconds



Please refer to http://forums.iis.net/t/1167753.aspx

------------------------------------------------------------------------
[2010-05-12 02:12:15] tser at deltacontrols dot com

More information.



Using the latest FastCGI update on IIS7 (KB980363) which support 

SignalBeforeTerminateSeconds, PHP_MSHUTDOWN_FUNCTION is still not being
called.



Look into the code in sapi/cgi/fastcgi.c

A thread fcgi_shutdown_thread has been created to trap the
"_FCGI_SHUTDOWN_EVENT_" 

event but the code simply set in_shutdown to 1. After that,
PHP_MSHUTDOWN_FUNCTION 

in the extension code is still not being called.

------------------------------------------------------------------------
[2010-01-12 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

------------------------------------------------------------------------
[2010-01-04 18:52:37] tser at deltacontrols dot com

To answer the question, the values of PHP_FCGI_MAX_REQUESTS and
instanceMaxRequests ar eboth 10000. But they do not come into play to
duplicate this problem. The problem could be duplicated before number of
request reach these numbers.



I will try to explain the detail using just the standard extension
(php_date).



1. Setup PHP FactCGI in IIS. Everything default.

2. Try to run a test.php with this code     <?phpinfo();?>

3. Attach the debugger to php_cgi.exe and make sure it loaded the debug
symbol of php_date.

4. Put a break point in PHP_MSHUTDOWN_FUNCTION inside php_date.c

5. Go to IIS Manager, Application Pools. Select DefaultAppPool and click
"Recycle..." on the right hand pane.

6. Notice that the php_cgi.exe will exit but your breakpoint in
php_date.c is not triggered.

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    http://bugs.php.net/bug.php?id=47412


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=47412&edit=1

Reply via email to