php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #4798 PHP/Apache sits in a loop
Submitted: 2000-06-03 23:10 UTC Modified: 2000-07-04 18:53 UTC
From: d dot rethans at jdimedia dot nl Assigned:
Status: Closed Package: Scripting Engine problem
PHP Version: 4.0.0 Release OS: Linux 2.2.13
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: d dot rethans at jdimedia dot nl
New email:
PHP Version: OS:

 

 [2000-06-03 23:10 UTC] d dot rethans at jdimedia dot nl 
The followings script describes a simple loop which never ends:

<?php
    do {
      printf ("test"); flush();
   } while (1==1);
?>

so i must hit the stop button in my browser to end this script. Unfortunately, it seems that these processes
never stop. I've now ended up with a load average of 23.32 and 25 apache processes. After a very long time (30 mins) the most of these processes are gone, but some (1-8) still don't end.

Configure command: (same as with php3.0.12)
'./configure' '--with-apache=/dat/APACHE-PHP4/apache_1.3.12' '--with-gd'
'--with-ttf' '--with-mysql' '--with-pdflib' '--with-config-file-path=/etc/httpd'
'--enable-track-vars' '--enable-magiq-quotes' '--enable-memory-limit'

I tried the same with php-3.0.12, and no problemos.

Then I noted the option: ignore_user_abort. It seems that in php3.0.12 it defaults to off, en with php4.0.0 to on. Turning that option on in php.ini solved the whole thing. Then tried this in php 3.0.12:
I set the option ignore_user_abort to "on" in php3.ini; and I reloaded my little script. As soon as I pushed the "stop" button in the browser, the httpd proces shut down. I think this is a bug. If you require more information, feel free to contact me.

Derick Rethans

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-06-04 00:38 UTC] stas at cvs dot php dot net 
So what is the problem? PHP 4 seems to be OK, you said.
 [2000-06-04 15:27 UTC] d dot rethans at jdimedia dot nl 
DR>> The problem is that when I run a script which never ends, and I have the
DR>> option "ignore_user_abort" set to "yes" and i abort the script with the
DR>> "stop" button in Netscape, the httpd process stops after 90 minutes, or not
DR>> at all.

So, you set "ignore_user_abort" to yes, then it (surprise!) ignores abort
caused by stop button. What's the problem?

DR>> Isn't PHP4 supposed to stop the aborted script after the maximum
DR>> execution time, and in such way stop that particular httpd
DR>> process? Now it doesn't.

Ah, now I see what you mean. It should indeed stop, I think. Maybe it's a
bug, or whoever wrote this doesn't agree with me on that.
 [2000-07-04 16:00 UTC] stas at cvs dot php dot net 
Does it still happen in 4.0.1pl2?
 [2000-07-04 16:52 UTC] d dot rethans at jdimedia dot nl 
Yes, It still occurs with php 4.0.1/4.0.1pl2. Both my college and I (with our own build) have
this problem. I am now checking the latest cvs version.
 [2000-07-04 17:38 UTC] stas at cvs dot php dot net 
Does the same happen without "print" statement?
Note that execution time limit is a clean execution time for the process,
and if your print is generating some 3M/s of data, you probabrly will wait
forever until it would expire your time limit, because most of the time will be spent by passing your data to the client and not in the process.
 [2000-07-04 18:22 UTC] stas at cvs dot php dot net 
Does the same happen without "print" statement?
Note that execution time limit is a clean execution time for the process,
and if your print is generating some 3M/s of data, you probabrly will wait
forever until it would expire your time limit, because most of the time will be spent by passing your data to the client and not in the process.
 [2000-07-04 18:53 UTC] stas at cvs dot php dot net 
OK, I've found where the problem was - seems that it was a bug indeed. 
Please try latest CVS (don't forget to update Zend CVS) and see if it helps.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Oct 29 19:00:01 2025 UTC