<?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;

?>

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.

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

Do you have output buffering enabled?

> 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.

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.

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.

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.

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.

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).

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)

Can you get a backtrace of the crash?

> 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.

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

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...

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.

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.

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.

Fixing Version/OS/Summary...

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.

If you test the patch (it should apply to 4.3.x just the same) and tell me it works, yes!

So what version of 5.x will have this fix? The latest public release is 5.0.2, which is affected by this problem.

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.

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.

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... :(

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?

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.

w.r.t. Win32 AcceptEx errors, see: http://httpd.apache.org/docs-2.0/faq/error.html#error.acceptex