Description:
------------
Apache2 crashes after upgrading to PHP 4.4.2.  THe following is found in
the Apache's error log.

[Sat Jan 14 12:15:11 2006] [notice] Parent: child process exited with
status 3221225477 -- Restarting.
[Sat Jan 14 12:15:12 2006] [notice] Apache/2.0.55 (Win32) PHP/4.4.2
configured -- resuming normal operations
[Sat Jan 14 12:15:12 2006] [notice] Server built: Oct  9 2005 19:16:56
[Sat Jan 14 12:15:12 2006] [notice] Parent: Created child process 3700
[Sat Jan 14 12:15:14 2006] [notice] Child 3700: Child process is
running
[Sat Jan 14 12:15:14 2006] [notice] Child 3700: Acquired the start
mutex.
[Sat Jan 14 12:15:14 2006] [notice] Child 3700: Starting 250 worker
threads.

This only happens on my production system where MySQL is also installed.
 Everything works as expected on the test machine (which connects  to
the production database server).

Reproduce code:
---------------
All of my PHP apps crash.  Unfortunately, the index.php files are quite
large.  I have not yet isolated the offending code but I wanted to enter
a bug report since before others upgrade since 4.4.2 is a new release.

Expected result:
----------------
Page returned as expected without Apache2 crashing.

Actual result:
--------------
Browser shows the entire page but is still waiting for additional
input.

Please try using this CVS snapshot:

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

The latest version of PHP5 did not exhibit the problem.  
Unfortunately, I have web sites that are not PHP5 compatible.  The ones
that are compatible with PHP5 worked fine.

The original assumption was bogus.  The crash is independent of MySQL. 
There were differences between my test and production systems that I did
not detect at first.

The problem is actually an issue with fopen().

Here is some code to reproduce:

<?php
$url="http://www.php.net";

$xhtml = '';
if($filehandle = @fopen($url, 'rb')) {
	$xhtml = fread($filehandle, 4096);
	fclose($filehandle);

	echo "$xhtml";
}
?>

This can be run either from the command line or as a webpage.  In both
cases, PHP crashes.

Everthing works as expected when using the latest version of PHP5.

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

We don't really support threaded webservers either...

Backtrace for this bug: 

(gdb) run
Starting program: /usr/www/php/bin/php -n test.php
[New Thread 16384 (LWP 15426)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 15426)]
php_stream_url_wrap_http_ex (wrapper=0x83c6fa8, path=0x845f404
"Cache-Control: private\r\n", mode=0x845fb24 "r", options=4,
opened_path=0x0,
    context=0x0, redirect_max=20, header_init=1, tsrm_ls=0x83ae748) at
/root/apache/php-4.4.2/ext/standard/http_fopen_wrapper.c:399
399                             while (*e == '\n' || *e == '\r') {
(gdb) bt
#0  php_stream_url_wrap_http_ex (wrapper=0x83c6fa8, path=0x845f404
"Cache-Control: private\r\n", mode=0x845fb24 "r", options=4,
opened_path=0x0,
    context=0x0, redirect_max=20, header_init=1, tsrm_ls=0x83ae748) at
/root/apache/php-4.4.2/ext/standard/http_fopen_wrapper.c:399
#1  0x0816008b in php_stream_url_wrap_http (wrapper=0x83c6fa8,
path=0x845a984 "http://www.google.de/", mode=0x845fb24 "r", options=4,
    opened_path=0x0, context=0x0, tsrm_ls=0x83ae748) at
/root/apache/php-4.4.2/ext/standard/http_fopen_wrapper.c:560
#2  0x081957bd in _php_stream_open_wrapper_ex (path=0x845a984
"http://www.google.de/", mode=0x845fb24 "r", options=12,
opened_path=0x4, context=0x0,
    tsrm_ls=0x83ae748) at /root/apache/php-4.4.2/main/streams.c:2696
#3  0x0812b99d in php_if_fopen (ht=2, return_value=0x84547d4,
this_ptr=0x0, return_value_used=1, tsrm_ls=0x83ae748)
    at /root/apache/php-4.4.2/ext/standard/file.c:1143
#4  0x081c6d90 in execute (op_array=0x845a8ec, tsrm_ls=0x83ae748) at
/root/apache/php-4.4.2/Zend/zend_execute.c:1675
#5  0x081b54f0 in zend_execute_scripts (type=8, tsrm_ls=0x83ae748,
retval=0x0, file_count=3) at /root/apache/php-4.4.2/Zend/zend.c:934
#6  0x081883da in php_execute_script (primary_file=0xbffff4c0,
tsrm_ls=0x83ae748) at /root/apache/php-4.4.2/main/main.c:1753
#7  0x081c924b in main (argc=3, argv=0xbffff544) at
/root/apache/php-4.4.2/sapi/cli/php_cli.c:830

PS: you've right, this problem only happend with threaded-webservers
(Apache2-worker)

I have experienced the bug on SuSE Linux 9.3 (32bit) with Apache 2.0.55
in worker mode. PHP is also compiled as thread-safe. My reproduction
code:

<?php

file_get_contents('http://www.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.