#25266 [Fbk-Opn]: connection_status() ( see bug #22072 ).
ID: 25266 User updated by: avarnals at zigg dot net Reported By: avarnals at zigg dot net -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Linux 2.4.21 PHP Version: 4CVS-2003-12-15 New Comment: I have repeated the first test with php4-STABLE-200401041830 as an Apache module. The result is the same as before, i.e. the problem hasn't gone. Have you tested this yourself or are just asking me to re-try it every time there is a new PHP 4 'latest' version? Previous Comments: [2004-01-04 14:17:00] [EMAIL PROTECTED] 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 [2003-12-15 19:21:31] avarnals at zigg dot net I have just repeated the first simple test using php4-STABLE-200312152230 and Apache 2.0.48, with PHP loaded as an Apache module. The bug has not gone. I.e. the httpd process continues to run the script ( until halted by the PHP time limit ) after the browser's stop button has been used. [2003-08-26 22:05:10] avarnals at zigg dot net Description: See bug #22072. Since the above is now closed, I am creating this entry. Please accept my apologies if it would have been better added to 22072 instead. I wasn't aware of this potential problem until I saw it in the change log for 4.3.3, so I thought I'd test it. Something is still not right. I'm using PHP 4.3.3 with Apache 2.0.47. My first test was to see whether ignore_user_abort() works as expected. I used the very simple: ignore_user_abort ( false ); while ( 1 ); This makes it easy to spot in the process list using 'top'. I tested both using PHP as a dynamically loaded Apache module and the CGI binary. The latter had safe mode enabled, the former didn't; I don't know whether this can/should make any difference. In both cases the script continued to execute after I clicked on the browser's stop button and until its PHP enforced time limit was reached. I then went on to test ( using only the Apache module ) using the code suggested in bug report 22072: http://www.mpfreescene.com/test/?option=source As rather expected now, this continued to execute after I'd used the stop button. I went on to test by modifying the code as follows: - I set set_time_limit(15); so it would eventually be aborted by this limit. - I made $m very large. - Have the result of connection_status() written to a file each time round the loop. - I removed the sleep() call. I ran the script and used the stop button while it was running. It continued to execute until it had used 15 seconds of CPU time. Log file shows: httpd: PHP Fatal error: Maximum execution time of 15 seconds exceeded in... The final ( large ) output file contained all zeros and a final 2. So, it seems that PHP correctly detects and reports the case of a timeout, but not an abort. I noticed one other possibly odd thing while doing this. If PHP has output buffering enabled, the call to flush() results in the script being immediately shut down ( execution doesn't get to the line following flush() ). The result of connection_status() when called in exitfp() is then 1. If the flush() call is removed, the results as previously described are the same whether or not output buffering is enabled. I hope someone can make sense of all this! Do let me know if you would like any further information. -- Edit this bug report at http://bugs.php.net/?id=25266edit=1
#25266 [NoF-Opn]: connection_status() ( see bug #22072 ).
ID: 25266 User updated by: avarnals at zigg dot net Reported By: avarnals at zigg dot net -Status: No Feedback +Status: Open Bug Type: Apache2 related Operating System: Linux 2.4.21 PHP Version: 4.3.3 New Comment: I have just repeated the first simple test using php4-STABLE-200312152230 and Apache 2.0.48, with PHP loaded as an Apache module. The bug has not gone. I.e. the httpd process continues to run the script ( until halted by the PHP time limit ) after the browser's stop button has been used. Previous Comments: [2003-12-14 21:17:48] [EMAIL PROTECTED] 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-12-09 06:15:42] [EMAIL PROTECTED] 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 [2003-08-26 22:05:10] avarnals at zigg dot net Description: See bug #22072. Since the above is now closed, I am creating this entry. Please accept my apologies if it would have been better added to 22072 instead. I wasn't aware of this potential problem until I saw it in the change log for 4.3.3, so I thought I'd test it. Something is still not right. I'm using PHP 4.3.3 with Apache 2.0.47. My first test was to see whether ignore_user_abort() works as expected. I used the very simple: ignore_user_abort ( false ); while ( 1 ); This makes it easy to spot in the process list using 'top'. I tested both using PHP as a dynamically loaded Apache module and the CGI binary. The latter had safe mode enabled, the former didn't; I don't know whether this can/should make any difference. In both cases the script continued to execute after I clicked on the browser's stop button and until its PHP enforced time limit was reached. I then went on to test ( using only the Apache module ) using the code suggested in bug report 22072: http://www.mpfreescene.com/test/?option=source As rather expected now, this continued to execute after I'd used the stop button. I went on to test by modifying the code as follows: - I set set_time_limit(15); so it would eventually be aborted by this limit. - I made $m very large. - Have the result of connection_status() written to a file each time round the loop. - I removed the sleep() call. I ran the script and used the stop button while it was running. It continued to execute until it had used 15 seconds of CPU time. Log file shows: httpd: PHP Fatal error: Maximum execution time of 15 seconds exceeded in... The final ( large ) output file contained all zeros and a final 2. So, it seems that PHP correctly detects and reports the case of a timeout, but not an abort. I noticed one other possibly odd thing while doing this. If PHP has output buffering enabled, the call to flush() results in the script being immediately shut down ( execution doesn't get to the line following flush() ). The result of connection_status() when called in exitfp() is then 1. If the flush() call is removed, the results as previously described are the same whether or not output buffering is enabled. I hope someone can make sense of all this! Do let me know if you would like any further information. -- Edit this bug report at http://bugs.php.net/?id=25266edit=1
#25266 [Fbk-Opn]: connection_status() ( see bug #22072 ).
ID: 25266 User updated by: avarnals at zigg dot net Reported By: avarnals at zigg dot net -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Linux 2.4.21 PHP Version: 4.3.3 New Comment: I have just tested http://snaps.php.net/php4-STABLE-latest.tar.gz as both a CGI program and Apache 2 module. In both cases, PHP still continues to run after the browser's stop button has been used despite setting ignore_user_abort ( false ); Previous Comments: [2003-09-18 20:50:47] [EMAIL PROTECTED] 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 [2003-08-27 08:53:45] avarnals at zigg dot net No, user abort was what I was testing for. Please read my report more carefully. [2003-08-26 23:37:39] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php User abort applies only if the user stop page loading, having a php reach execution timeout will not trigger abort. [2003-08-26 22:05:10] avarnals at zigg dot net Description: See bug #22072. Since the above is now closed, I am creating this entry. Please accept my apologies if it would have been better added to 22072 instead. I wasn't aware of this potential problem until I saw it in the change log for 4.3.3, so I thought I'd test it. Something is still not right. I'm using PHP 4.3.3 with Apache 2.0.47. My first test was to see whether ignore_user_abort() works as expected. I used the very simple: ignore_user_abort ( false ); while ( 1 ); This makes it easy to spot in the process list using 'top'. I tested both using PHP as a dynamically loaded Apache module and the CGI binary. The latter had safe mode enabled, the former didn't; I don't know whether this can/should make any difference. In both cases the script continued to execute after I clicked on the browser's stop button and until its PHP enforced time limit was reached. I then went on to test ( using only the Apache module ) using the code suggested in bug report 22072: http://www.mpfreescene.com/test/?option=source As rather expected now, this continued to execute after I'd used the stop button. I went on to test by modifying the code as follows: - I set set_time_limit(15); so it would eventually be aborted by this limit. - I made $m very large. - Have the result of connection_status() written to a file each time round the loop. - I removed the sleep() call. I ran the script and used the stop button while it was running. It continued to execute until it had used 15 seconds of CPU time. Log file shows: httpd: PHP Fatal error: Maximum execution time of 15 seconds exceeded in... The final ( large ) output file contained all zeros and a final 2. So, it seems that PHP correctly detects and reports the case of a timeout, but not an abort. I noticed one other possibly odd thing while doing this. If PHP has output buffering enabled, the call to flush() results in the script being immediately shut down ( execution doesn't get to the line following flush() ). The result of connection_status() when called in exitfp() is then 1. If the flush() call is removed, the results as previously described are the same whether or not output buffering is enabled. I hope someone can make sense of all this! Do let me know if you would like any further information. -- Edit this bug report at http://bugs.php.net/?id=25266edit=1
#25266 [NEW]: connection_status() ( see bug #22072 ).
From: avarnals at zigg dot net Operating system: Linux 2.4.21 PHP version: 4.3.3 PHP Bug Type: Apache2 related Bug description: connection_status() ( see bug #22072 ). Description: See bug #22072. Since the above is now closed, I am creating this entry. Please accept my apologies if it would have been better added to 22072 instead. I wasn't aware of this potential problem until I saw it in the change log for 4.3.3, so I thought I'd test it. Something is still not right. I'm using PHP 4.3.3 with Apache 2.0.47. My first test was to see whether ignore_user_abort() works as expected. I used the very simple: ignore_user_abort ( false ); while ( 1 ); This makes it easy to spot in the process list using 'top'. I tested both using PHP as a dynamically loaded Apache module and the CGI binary. The latter had safe mode enabled, the former didn't; I don't know whether this can/should make any difference. In both cases the script continued to execute after I clicked on the browser's stop button and until its PHP enforced time limit was reached. I then went on to test ( using only the Apache module ) using the code suggested in bug report 22072: http://www.mpfreescene.com/test/?option=source As rather expected now, this continued to execute after I'd used the stop button. I went on to test by modifying the code as follows: - I set set_time_limit(15); so it would eventually be aborted by this limit. - I made $m very large. - Have the result of connection_status() written to a file each time round the loop. - I removed the sleep() call. I ran the script and used the stop button while it was running. It continued to execute until it had used 15 seconds of CPU time. Log file shows: httpd: PHP Fatal error: Maximum execution time of 15 seconds exceeded in... The final ( large ) output file contained all zeros and a final 2. So, it seems that PHP correctly detects and reports the case of a timeout, but not an abort. I noticed one other possibly odd thing while doing this. If PHP has output buffering enabled, the call to flush() results in the script being immediately shut down ( execution doesn't get to the line following flush() ). The result of connection_status() when called in exitfp() is then 1. If the flush() call is removed, the results as previously described are the same whether or not output buffering is enabled. I hope someone can make sense of all this! Do let me know if you would like any further information. -- Edit bug report at http://bugs.php.net/?id=25266edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25266r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25266r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25266r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25266r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25266r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25266r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25266r=support Expected behavior: http://bugs.php.net/fix.php?id=25266r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25266r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25266r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25266r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25266r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25266r=dst IIS Stability: http://bugs.php.net/fix.php?id=25266r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25266r=gnused
#25266 [Bgs-Opn]: connection_status() ( see bug #22072 ).
ID: 25266 User updated by: avarnals at zigg dot net Reported By: avarnals at zigg dot net -Status: Bogus +Status: Open Bug Type: Apache2 related Operating System: Linux 2.4.21 PHP Version: 4.3.3 New Comment: No, user abort was what I was testing for. Please read my report more carefully. Previous Comments: [2003-08-26 23:37:39] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php User abort applies only if the user stop page loading, having a php reach execution timeout will not trigger abort. [2003-08-26 22:05:10] avarnals at zigg dot net Description: See bug #22072. Since the above is now closed, I am creating this entry. Please accept my apologies if it would have been better added to 22072 instead. I wasn't aware of this potential problem until I saw it in the change log for 4.3.3, so I thought I'd test it. Something is still not right. I'm using PHP 4.3.3 with Apache 2.0.47. My first test was to see whether ignore_user_abort() works as expected. I used the very simple: ignore_user_abort ( false ); while ( 1 ); This makes it easy to spot in the process list using 'top'. I tested both using PHP as a dynamically loaded Apache module and the CGI binary. The latter had safe mode enabled, the former didn't; I don't know whether this can/should make any difference. In both cases the script continued to execute after I clicked on the browser's stop button and until its PHP enforced time limit was reached. I then went on to test ( using only the Apache module ) using the code suggested in bug report 22072: http://www.mpfreescene.com/test/?option=source As rather expected now, this continued to execute after I'd used the stop button. I went on to test by modifying the code as follows: - I set set_time_limit(15); so it would eventually be aborted by this limit. - I made $m very large. - Have the result of connection_status() written to a file each time round the loop. - I removed the sleep() call. I ran the script and used the stop button while it was running. It continued to execute until it had used 15 seconds of CPU time. Log file shows: httpd: PHP Fatal error: Maximum execution time of 15 seconds exceeded in... The final ( large ) output file contained all zeros and a final 2. So, it seems that PHP correctly detects and reports the case of a timeout, but not an abort. I noticed one other possibly odd thing while doing this. If PHP has output buffering enabled, the call to flush() results in the script being immediately shut down ( execution doesn't get to the line following flush() ). The result of connection_status() when called in exitfp() is then 1. If the flush() call is removed, the results as previously described are the same whether or not output buffering is enabled. I hope someone can make sense of all this! Do let me know if you would like any further information. -- Edit this bug report at http://bugs.php.net/?id=25266edit=1
