This is the way it works and this is expected.

I don't see why.

Additionally, as far as I remember, the behaviour is 
different with mod_php: the error gets displayed in the 
browser (with display_errors "on") and therefor probably 
also get logged into the virtual host's error log.

IMHO it's very confusing to just have the error, without 
any time, file or vhost information in the main error.log!

PHP has nothing to do with your web server logging utilities.

Apache does not attach the "in FILE on LINE" to the error 
PHP creates!

Re: "mod_fastcgi logs FastCGI application error (stderr) 
output to the server log associated with the request. 
Errors reported by the FastCGI process manager, fcgi-pm, 
are reported to the main server log (typically, 
logs/error_log). Data written to stdout or stderr before 
entering the FastCGI accept loop or via a mechanism that 
is not FastCGI protocol aware will also be directed to the 
main server log." 
(http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html)
it seems that the "memory exhausted" error is "Data 
written to stdout or stderr before entering the FastCGI 
accept loop or via a mechanism that is not FastCGI 
protocol aware".

I also don't see any reason why mod_php would 
display/deliver the page that has been processed/created 
before this error, but the php-fastcgi returns an invalid 
response.

Probably this is configuration problem. Try the following directives in your php.ini

log_errors=E_ALL
report_zend_debug=0

They may satisfy your expectation (work for me).

I cannot reproduce server interanl error and "Connection reset by peer" and "incomplete headers" messages. Please confirm that you still have the problem or close the bug.

I have
log_errors=On (rather than E_ALL)
error_reporting=E_ALL
and
error_log not set.

IF I set error_log to some file, the fatal error gets 
logged there:
[24-May-2006 19:11:49] PHP Fatal error:  Allowed memory 
size of 1048576 bytes exhausted (tried to allocate 6 
bytes) in /XXX/web/test/memory.php on line 10

In the Apache main error.log I then get:
Allowed memory size of 1048576 bytes exhausted (tried to 
allocate 44 bytes)
[Wed May 24 19:14:24 2006] [warn] FastCGI: 
server "/XXX/fcgi-scripts/XXX/php5-fcgi-starter" (pid 
2637) terminated by calling exit with status '1'
[Wed May 24 19:14:24 2006] [warn] FastCGI: 
server "/XXX/fcgi-scripts/XXX/php5-fcgi-starter" (uid 
1001, gid 1001) restarted (pid 2767)

and in the VHOST's error log:
[Wed May 24 19:14:24 2006] [error] [client X] 
(104)Connection reset by peer: FastCGI: comm with 
server "/XXX/fcgi-scripts/XXX/php5-fcgi-starter" aborted: 
read failed
[Wed May 24 19:14:24 2006] [error] [client X] FastCGI: 
incomplete headers (0 bytes) received from 
server "/XXX/fcgi-scripts/XXX/php5-fcgi-starter"

IMHO, with error_log set it's even more bad: the 
fcgi-starter script exits, although I'm using 
PHP_FCGI_CHILDREN=4!

report_zend_debug does not seem to make a difference, and 
is "On" by default (not in my php.ini?!)

I've just tested it with current CVS PHP_5_1.

Could you retest it with current PHP_5_2. New memory manager may fix this problem.

It works!

Though it's now a bit too verbose (reference to source 
code/zend_operators).


VirtualHost log:

[Thu Jul 20 00:00:04 2006] [error] [client X] FastCGI: 
server "/X/php5-fcgi-starter" stderr: PHP Fatal error:  
Allowed memory size of 1048576 bytes exhausted 
at /X/cvs/php/PHP_5_2/Zend/zend_operators.c:1183 (tried to 
allocate 786358 bytes) in /X/public_html/bug_37481.php on 
line 6


Main server error log:
/X/public_html/bug_37481.php(6) : Fatal error - Allowed 
memory size of 1048576 bytes exhausted 
at /X/cvs/php/PHP_5_2/Zend/zend_operators.c:1183 (tried to 
allocate 786358 bytes)

Fixed -> closed.

Should I open another bug because the (now working) error message is too verbose??

Re-opened, because it's too verbose - there should be no 
reference to Zend/zend_operators.c:1183.

Just re-tested with PHP_5_2

The error message is the same everywhere and it includes some debug information required to understand where exactly the memory was exhausted.
We're not going to change it just because you consider it too verbose.