Please try using this CVS snapshot:

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

I've just upgraded to 5.2.2-dev as you suggested, and that hasn't fixed the problem.

My server is still dying as soon as a connection gets aborted.

I am not able to reproduce the problem.

I tried to abort downloading from IE and download part of file running the following PHP script from command line:

<?php
$f = fopen("http://127.0.0.1/test/bug40556.php", "r");
$s = fread($f, 1024*1024);
var_dump($s);
fclose($f);
?>

both cases work fine (Apache-1.3.28 with mod_fastcgi or ZendEnabler on Linux 2.6.19)

OK, I've done quite a lot more testing, and here are the results (Apache 2.0.59/mod_fastcgi 2.4.2/PHP 5.2.1):

- I cannot reproduce the bug with your code either.

- The following code causes PHP workers to lock up if you abort during download (and only if you abort):

             http://www.slashorg.net/ex/crash.txt

Note: notice the "session_start();" line

- If I remove the "session_start();" line, PHP doesn't crash anymore, even when I abort the download.


It seems this bug is more complicated than I thought, I hope you'll be able to reproduce it.

Thanks for your help.

I am still not able to reproduce the problem.
Could you please attach debugger to stuck php process and show its backtrace.

Hello,

I haven't really used gdb before, I obtain a backtrace? I guess I have to recompile php with debug support?

Thanks.

>I guess I have to recompile php with debug support?
Yes, rebuild with --enable-debug is required.
- start PHP/FastCGI with just one process (-processes 1) 
- figure out pid of PHP (ps afx | grep php or see Apache error_log)
- start gdb (just type gdb and enter), then type "attach <pid of php>", this way you'll attach to already running PHP process.
- type "continue" for the process to continue running.
- after that reproduce the problem and see if the process stops.
- if it does, type "backtrace" and paste the output here.
- if it doesn't we'll continue in the next post.

You can also create an account on the server, I'll try to reproduce it myself. 

Here's a backtrace, tell me if this helps you:

(gdb) attach 1774
Attaching to process 1774.
Reading symbols for shared libraries . done
Reading symbols for shared libraries ................ done
0x900101b7 in write ()
(gdb) backtrace
#0  0x900101b7 in write ()
#1  0x004007c4 in safe_write (req=0x0, buf=0xbffffeb4, count=0) at /home/unreal/compile/php-5.2.1/sapi/cgi/fastcgi.c:351
#2  0x00002095 in start ()
(gdb)

Some more information:

The issue only seems to appear when the client abandons the connection without ending the http session properly. For example, we have an antivirus gateway appliance that drops the connection with a tcp-reset when the browser cancels. PHP doesn't seem to get informed that the connection has ended and becomes non responsive until some timeout (?) occures. If I use "lsof" while the php process is blocked, I can see the process is still accessing the download file...

>Here's a backtrace, tell me if this helps you
The backtrace shows that write() syscall blocks when trying to write to an invalid socket.
Not something PHP can fix..

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Try calling 
session_write_close();
before reading the file.