Please try using this CVS snapshot:

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

For Windows (installer):

  http://snaps.php.net/win32/php5.2-win32-installer-latest.msi

I can't reproduce anything like this, even when uploading quite large files so try the snapshot first. (any possibility that this isn't any PHP bug at all..? :)

Right, I was taken that already in consideration and posted a report on "mod_fcgid users bug tracker" as well. But looking at the history of somewhat related php-cgi problems and bug reported I think it is more likely to be a PHP bug.

My problem is that I have a hosting service and I rely on both PHP5 & PHP4 because I do have clients who still have PHP4 applications they want to run. So even if it does work with the latest CVS (which I will try out) I still have a need for this feature to run on PHP4 as well. :(

Ok, I checked the latest CVS snapshot but the problem still remains the same.

I forgot to mention in my inital post that I am using Apache2 with mod_suexec for permissions. But that seems to work fine according to suexec.log and apache2 error.log files. Thought I mention it now anyway just in case.

Regarding any PHP 4 fixes, see php.net for latest NEWS: "PHP 4 end of life announcement"

This isn't any critical issue so it's very unlikely it will get fixed in PHP 4 (even if there were any more releases of PHP 4..)

And I still think this isn't PHP bug. Do you know if PHP is outputting any errors? Do you have logging enabled? Are you sure you haven't hit any limits set in php.ini for max size for uploaded file for example..?

Yeah I saw the news "PHP 4 end of life announcement" and I know that bug reports for it probably won't be fixed unless they are critical issues. I find it funny that both PHP versions are behaving like that...

I checked the PHP config for this vhost again and again and tried different settings:

Right now I have:
------------------
max_execution_time = 60
max_input_time = 120
memory_limit = 64M
error_reporting  =  E_ALL & ~E_NOTICE
display_errors = On
log_errors = On
log_errors_max_len = 1024

But even after some testing now, still no PHP error.log to be seen!?

You forgot to set 'error_log = /path/to/php_error.log' 

Sorry I forgot to add that.. I had a path set but only the path not the  filename. Well so this time PHP did create a log but nothing in it when the "500 Internal Error" occurs. Well how should it write into the log when all the processes are killed at once!?

Good point. :)

My guess is it's crashing so you should try and attach GDB to the running process and see what the crash is about (note: you need to use latest CVS snapshot configured using --enable-debug option!)

Make sure you only start 1 PHP FastCGI child, check what it's pid is and attach gdb:

# gdb /path/to/php-cgi <pid>

what is the value of MaxRequestsPerProcess in your mod_fcgid configuration, it should be -1 

This is a known issue of mod_fcgid see the documentation

http://fastcgi.coremail.cn/doc.htm

This is not a bug in PHP.

err.. I meant it should be set to 500 NOT -1

@jani

Ok will do and let you know what the result is.

@crrodriguez

Here is my config for mod_fcgid:
----------------------------------
<IfModule fcgid_module>
SharememPath /tmp/fcgid_shm
SocketPath /opt/local/apache2/logs/fcgidsock
IPCConnectTimeout 60
IPCCommTimeout 60
MaxRequestsPerProcess 500
MaxRequestInMem 1500000
MaxRequestLen 1500000
</IfModule>

I think I have tried EVERY possible combination there is. I read ALL the threads and issues posted on sourceforge page as well as pretty much every thread I could find on google regarding mod_fcgid issues. :( That's why I am quite desperate to solve this.

Thanks for you help...

Ok, now here is the output for latest CVS:

Attaching to program: `/usr/local/bin/php-cgi', process 25912.
Reading symbols for shared libraries .. done
0x9004eb97 in accept ()
(gdb) c
Continuing.

Program received signal SIGPIPE, Broken pipe.
0x9001029c in write ()
(gdb) bt
#0  0x9001029c in write ()
#1  0x002e79b3 in fcgi_flush (req=0xbfffdc00, close=1) at /usr/local/php5.2-200708230830/sapi/cgi/fastcgi.c:543
#2  0x002e7a29 in fcgi_finish_request (req=0xbfffdc00) at /usr/local/php5.2-200708230830/sapi/cgi/fastcgi.c:1163
#3  0x002e825f in fcgi_accept_request (req=0xbfffdc00) at /usr/local/php5.2-200708230830/sapi/cgi/fastcgi.c:869
#4  0x002ea880 in main (argc=1, argv=0xbffffdd0) at /usr/local/php5.2-200708230830/sapi/cgi/cgi_main.c:1491

Any news on this?

Check for these setting in the phpinfo() output for the failing vhost:

post_max_size = 8M
upload_max_filesize = 2M

Is set to:

post_max_size = 8M
upload_max_filesize = 6M

However, I have some good news but not sure if that still does not effect PHP as well anyway. I now tried to run this completely WITHOUT mod_fcgid/mod_fastcgi just as plain and simple CGI. And it does work then without ANY flaws. I guess that means PHP CGI is alright and it's all because of mod_fcgid? Or is PHP executed any different when running thru mod_fcgid/mod_fastcgi?

It is different. But I can't reproduce it using lighttpd so I'd say it's not PHP bug at all. I suggest you ditch Apache and move to the lighttpd camp. :) 

If you can reproduce this with lighttpd, reopen.