#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: The problem is still there with php4-STABLE-200401120230 as an Apache module. Previous Comments: [2004-01-11 11:38:48] [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 [2004-01-04 15:24:33] avarnals at zigg dot net 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? [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=25266&edit=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: 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=25266&edit=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=25266&edit=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=25266&edit=1
#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=25266&edit=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=25266&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25266&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25266&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25266&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25266&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25266&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25266&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25266&r=support Expected behavior: http://bugs.php.net/fix.php?id=25266&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25266&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25266&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25266&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25266&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25266&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25266&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25266&r=gnused
#20138 [NEW]: PHP 4.3.0-pre2 fails to parse .php files with Apache 2.0.43
From: [EMAIL PROTECTED] Operating system: Linux 2.4.19 PHP version: 4.3.0-pre1 PHP Bug Type: Apache related Bug description: PHP 4.3.0-pre2 fails to parse .php files with Apache 2.0.43 This is actually about 4.3.0-pre2 ( I haven't tried pre1 ). PHP was configured with: --with-apxs2=/usr/local/apache2/bin/apxs --prefix=/usr/local/php --without-mysql --with-pgsql --with-gd --with-openssl --with-zlib --with-jpeg-dir=/usr --with-png-dir=/usr --with-bz2 -enable-ftp --enable-bcmath (It failed to find libjpeg and libpng in /usr/lib without the relevant options above. ) I manually added: LoadModule php4_module modules/libphp4.so and: AddType application/x-httpd-php .php to httpd.conf, APXS getting the fromer wrong, though I note that 'make install' with PHP 4.2.3 and Apache 2 does do the right thing. 'make test' resulted in two failures: FAIL OpenSSL private key functions [ext/openssl/tests/001.phpt] FAIL Testing randomization of shuffle() and str_shuffle(). [ext/standard/tests/strings/004.phpt] I wouldn't have thought, but don't know, that these are not relevant to my problem. Anyway, the main problem is that .php files are not being parsed when served, my browser prompting me to save the file instead. The browser informs me that it is a file of type application/x-httpd-php, so it seems the AddType directive is working. It looks as if Apache is loading the PHP module: HTTP/1.1 200 OK Date: Mon, 28 Oct 2002 18:22:51 GMT Server: Apache/2.0.43 (Unix) mod_ssl/2.0.43 OpenSSL/0.9.6e PHP/4.3.0-pre2 and fuser reports that libphp4.so is held open by each of the Apache processes. The Apache configuration is almost as the supplied default, but with two virtual servers enabled. I've tested without virtual servers and the same problem occurs. PHP 4.2.3 with the same Apache configuration does work, other than the known problem of the segmentation faults on trying to make the server re-read its configuration. -- Edit bug report at http://bugs.php.net/?id=20138&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20138&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20138&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20138&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20138&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20138&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20138&r=support Expected behavior: http://bugs.php.net/fix.php?id=20138&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20138&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20138&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20138&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20138&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20138&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20138&r=isapi
