php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #25570 Some requests cause Apache to crash/restart
Submitted: 2003-09-17 03:24 UTC Modified: 2004-10-26 14:30 UTC
Votes:7
Avg. Score:4.9 ± 0.3
Reproduced:7 of 7 (100.0%)
Same Version:2 (28.6%)
Same OS:3 (42.9%)
From: robert at profundis dot se Assigned: jorton (profile)
Status: Closed Package: Apache2 related
PHP Version: 5CVS-2004-04-22 (dev) OS: WinXP SP1
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: robert at profundis dot se
New email:
PHP Version: OS:

 

 [2003-09-17 03:24 UTC] robert at profundis dot se
Description:
------------
Platform:
Apache 2.0.47 / PHP 4.3.3
Windows XP Pro SP 1

Problem:
It is similar to bug 24958 (http://bugs.php.net/bug.php?id=24958), reportedly fixed a while ago, but...

In short: Sometimes a request cause Apache/PHP to crash, and restart itself.

This first came to my attention when a visitor complained that very often two pages failed to load (the notorious IE "error" message). I noticed that these two pages where the largest PHP generated ones, 12 & 14k while others were about 5-6k. A sniff revealed that the TCP session was terminated immediately after the request to these pages.

I then noticed in Apache's error log a frequent line:
"[notice] Parent: child process exited with status 4294967295 -- Restarting"

I now understood that this happens from time to time to others as well, but that the request was resubmitted so it simply produced a little delay while Apache was restarting. However, I cause Apache to crash perhaps 1 time in 20 requests to this page, while this visitor seem to do it 3 times in 4 requests. No clue what would make this difference.

I am now usually able to reproduce this myself, by quickly reloading the page; the bigger the output, the more likely it is to cause the crash.

A document like this:

<?php for($i; $i < 15000; ++$i) echo '-'; ?>

And requesting it two times in perhaps 2/10 second, will in almost all cases cause the crash.

I have also verified this behaviour in the latest stable 4.3.4-dev build (php4-win32-STABLE-200309170430.zip).

I cannot trace this crashing (in the log) before a few days ago when I upgraded from 4.3.1-dev to 4.3.3.

Regards,
Robert Andersson


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-09-17 04:39 UTC] lys_007 at yahoo dot it
<?php

  // OS: Win 2000 Professional
  // Apache 2.0.47
  // PHP 4.3.3
  // It worked on older versions of PHP/Apache,
  // on PHP 4.3.3/Apache 2.0.47 it causes a browser 
  // crash

  $todisplay = "";
  for($i = 0; $i < 300000; $i++) {
    $todisplay .= "Hello word<br>\n";
  }
  echo $todisplay;

?>
 [2003-09-17 05:48 UTC] robert at profundis dot se
After some investigation it seems as this bug was introduced in PHP 4.3.3RC3. I have tested the following versions:

4.3.2     -- OK
4.3.3RC1  -- ?
4.3.3RC2  -- OK
4.3.3RC3  -- Crash
4.3.3RC4  -- Crash
4.3.3     -- Crash
4.3.4-dev -- Crash

With the versions designated 'OK', I was unable to reproduce the bug. The '?', I didn't test.

I performed the test by constantly reloading (holding down F5) on a <?php phpinfo(); ?> document.
 [2003-09-17 06:43 UTC] robert at profundis dot se
Another piece of info. While testing a script like:

    for($i = 0; $i < 15000; ++$i) $output .= '-';
    echo $output;

The script (and server) dies inside the echo() function. Still it occurs seldom, usually when the script hasn't been executed for a while, or when brutally reloading the page.

Regards,
Robert Andersson
 [2003-09-17 18:57 UTC] iliaa@php.net
Do you have output buffering enabled?
 [2003-09-17 19:19 UTC] robert at profundis dot se
> Do you have output buffering enabled?

No. My tests has been with fresh/default installations of both Apache and PHP.

I did now test to set output_buffering = On, in php.ini. phpinfo() reports it to set to '1' (rather than 'On'). The problem remains, and perhaps somewhat more frequent with this setting.

Any pointers as how to debug PHP under Windows are welcome, I haven't been able to find any information about this.
 [2003-09-18 05:08 UTC] robert at profundis dot se
I did some debugging on my own, and concluded that if two requests overlap, it will crash. I did some primitive logging in apache2handler/sapi_apache2.c/php_handler(), and noticed that the last function to be called was php_handle_aborted_connection(), then Apache crashed and restarted. This was in cases where the second request entered php_handler() before the first had left it.

While looking through changes of this source file in the CVS, I noticed diff 1.1.2.17-18 (http://cvs.php.net/diff.php/php-src/sapi/apache2handler/sapi_apache2.c?login=2&r1=1.1.2.17&r2=1.1.2.18&ty=h) which was commit just after 4.3.3RC2 (which doesn't crash). Could it possibly be related? I do currently not have the ability to revert the change and recompile, but I will do so later.
 [2003-09-18 08:54 UTC] robert at profundis dot se
By changing three lines in
sapi/apache2handler/sapi_apache2.c, back to how they were in rev. 1.1.2.17, it would not crash anymore on overlapping requests. Ie:

// in 1.1.2.18
if (ap_pass_brigade(r->output_filters, brigade)
    != APR_SUCCESS || r->connection->aborted)

// in 1.1.2.17
if (ap_pass_brigade(r->output_filters, brigade)
    != APR_SUCCESS)

I cannot really guess what implications that change has, but I assume the extra expression had a purpose. However, with this change I cannot generate a crash anymore.
 [2003-09-18 20:43 UTC] iliaa@php.net
This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.


 [2004-10-14 16:52 UTC] christopher_theunissen at hotmail dot com
This bug is definitely not fixed or has resurfaced, as I have the same problem in Windows 2000 with Apache 2.0.52 (51, 40, 49, 48) and the following PHP versions:
  5.0.2
  5.0.1
  4.3.9
  4.3.8
  4.3.4
  4.3.3

The server restarts with status 4294967295 every few hours.

It has been running fine for 24 hours so far with PHP 4.3.2.
 [2004-10-14 17:09 UTC] robert at profundis dot se
I change this to Open again.

As Christopher said, this bug seems to have resurfaced. I checked back in my error log, and I see this same error started happening again the 3rd of september. Checking my notes, I upgraded this server to PHP 4.3.8 a few days earlier. The previous version was 4.3.4-dev (I had been lazy).
 [2004-10-14 17:20 UTC] robert at profundis dot se
The only change in the code that seems to be related at a first glance is in rev 1.1.2.32:
http://cvs.php.net/diff.php/php-src/sapi/apache2handler/sapi_apache2.c?r1=1.1.2.31&r2=1.1.2.32&ty=u

The original problem seems to be triggered when calling php_handle_aborted_connection() on some occasions. The above revision change the condition when this function is called.

I have not tested the versions inbetween 4.3.4-dev and 4.3.8, so I cannot confirm that this particular revision is the "cause".

(I also changed this bug's version number)
 [2004-10-14 18:38 UTC] jorton@php.net
Can you get a backtrace of the crash?
 [2004-10-14 20:34 UTC] robert at profundis dot se
> Can you get a backtrace of the crash?

Eek, not easily. This is Windows :(  Not saying one can't make a backtrace on Windows, but I'm not sure how to go about doing it.

Last time around I had a test machine to tinker with, not so this time.

My guess is that it is a thread issue, since it occurs when two requests (threads) are inside the handler, and one of them is aborted (according to my investigations last time). I'm not too familiar with the code, but maybe some overlooked global related to aborted connections?

I can also add that I can't say for sure it ever was fixed. I don't remember if the version I've been running was the one I modified myself or a cvs snapshot.
 [2004-10-15 14:40 UTC] jonathan at schwarzelan dot de
Some extra Information on the Bug
(sorry no traces-)

Not only outputting stuff leads to this error - 
Just having a loop of 140 doing querys on mysql
and without saving data from those querys filling an array
like $arr[$i][0]="" crashes Apache with said logfile occurence - 

Found with Win2k, Php 5.1.0-dev and 2.0.50 Apache
and XPSP1, Php 5.0.2 release and 2.0.50 Apache
 [2004-10-15 14:42 UTC] jonathan at schwarzelan dot de
Sorry guys - got to correct the above said...

With outputting results in the 4294967295 Crash - 
without it results to 3221225477 Apache crash

shame on me...
 [2004-10-17 18:55 UTC] mwhitlock at whitsoftdev dot com
Unsigned 4294967295 is the same as -1 in 32-bit two's complement signed math.  It looks to me as if we're not encountering a segfault (since that would generate a different message in httpd.log) but rather an error trap somewhere that is calling exit(-1).  Calling exit(..) from a dynamic link library kills the host process, which in this case would be the Apache child process.  Seems like the solution is just finding where PHP is calling exit(-1) and changing it to somehow more gracefully aborting the request rather than forcefully exiting the process.  Exiting the process wouldn't be a problem for the CLI since a separate process is created to handle every request, but as an Apache module, exit(..) is simply wrong.
 [2004-10-20 10:47 UTC] jorton@php.net
Ah, good call.  The interesting exit(-1) call is in Zend: _zend_bailout to be specific.

And in fact zend_bailout is called from php_handle_aborted_connection, which can be called outside the zend_first_try/zend_end_try block in the 2.0 SAPI, so that looks like the bug.


 [2004-10-21 10:28 UTC] jorton@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip

I've committed a possible fix for this to 5.0 and 5.1, please apply:

http://cvs.apache.org/~jorton/php_abort.diff

or wait for a 5.0-dev or 5.1-dev snapshot to show up with this applied.
 [2004-10-21 10:48 UTC] jorton@php.net
Fixing Version/OS/Summary...
 [2004-10-21 11:00 UTC] robert at profundis dot se
Will the fix be applied to 4.x.x as well? I'm not really ready for the leap to v5 for production just yet.
 [2004-10-21 11:31 UTC] jorton@php.net
If you test the patch (it should apply to 4.3.x just the same) and tell me it works, yes!
 [2004-10-21 16:35 UTC] joel at preacherboy dot net
So what version of 5.x will have this fix? The latest public release is 5.0.2, which is affected by this problem.
 [2004-10-21 20:53 UTC] aaron at gwmicro dot com
Sorry about the double post in 30405. With the latest 5.1.X CVS build (Oct 21, 2004 18:30 GMT), this problem has been resolved for me. Thank you.
 [2004-10-21 21:44 UTC] jorton@php.net
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

Thanks for testing it out.  The fix has been included in the 4.3 branch now too so it should be included in the next 4.3.x and 5.0.x releases.
 [2004-10-22 17:02 UTC] sintemaa at hotmail dot com
Any idea when 4.3.10 will be released.

Currently I'm a bit caught in a split. I'm running 4.3.6 and I need to upgrade to a new version, but when I upgrade to 4.3.9 I get these problems... :(
 [2004-10-25 20:06 UTC] FaithPast at gmail dot com
Hello, 
this is the second time i will try posting this here.

Running: 
-----------------------------
Apache 2.0.52
mod_ssl 0.9.7d
PHP 5.1.x (WITH CVS version as of noon 10/24/2004)
win2k server

So far it has reduced the issue dramaticly about how often the server returns a "Page not found" error. 
However this issue still is there. Once every X minutes Apache2 restarts herself and durring that 1 - 3 second gap while restarting any requests are returned with a PNF error.

Now is this an Apache2 issue? or PHP?
 [2004-10-26 13:58 UTC] suco at felisuco dot com
Hello, 

Running: 
-----------------------------
Apache 2.0.52
PHP 4.3.9 CVS version as of noon 10/26/2004)
win2003 server

Hi I have the same problems, the errors has reduced dramaticly but the error is still there:

[Tue Oct 26 13:28:44 2004] [warn] (OS 121)Ha terminado el intervalo de espera del sem?foro.  : winnt_accept: Asynchronous AcceptEx failed.
[Tue Oct 26 13:29:49 2004] [warn] (OS 64)El nombre de red especificado ya no est? disponible.  : winnt_accept: Asynchronous AcceptEx failed.
[Tue Oct 26 13:31:57 2004] [warn] (OS 64)El nombre de red especificado ya no est? disponible.  : winnt_accept: Asynchronous AcceptEx failed.
[Tue Oct 26 13:37:53 2004] [warn] (OS 64)El nombre de red especificado ya no est? disponible.  : winnt_accept: Asynchronous AcceptEx failed.
[Tue Oct 26 13:42:11 2004] [warn] (OS 64)El nombre de red especificado ya no est? disponible.  : winnt_accept: Asynchronous AcceptEx failed.
[Tue Oct 26 13:43:03 2004] [warn] (OS 64)El nombre de red especificado ya no est? disponible.  : winnt_accept: Asynchronous AcceptEx failed.
[Tue Oct 26 13:45:19 2004] [warn] (OS 64)El nombre de red especificado ya no est? disponible.  : winnt_accept: Asynchronous AcceptEx failed.
[Tue Oct 26 13:45:26 2004] [warn] (OS 64)El nombre de red especificado ya no est? disponible.  : winnt_accept: Asynchronous AcceptEx failed.
 [2004-10-26 14:30 UTC] jorton@php.net
w.r.t. Win32 AcceptEx errors, see: http://httpd.apache.org/docs-2.0/faq/error.html#error.acceptex
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Dec 11 00:01:28 2024 UTC