Description:
------------
I just downloaded

Stable (4.4.x-dev)
Built On: Nov 03, 2005 23:51 GMT

and built it:

PHP 4.4.2-dev (cli) (built: Nov  4 2005 02:17:10)

But it seems like, the following bug is _not_ fixed
in that snapshot:

http://bugs.php.net/bug.php?id=35059

This happens with _any_ RewriteRule I use.

Reproduce code:
---------------
Try to use mod_rewrite on Apache 2.x to modify any URL.
Small test case:

index.php:
<?php echo($_GET['myarg']); ?>

RewriteRule:
RewriteRule ^(.+)/$ index.php?myarg=$1 [L]

URLs to try:
1. http://localhost/index.php?myarg=bla
2. http://localhost/blub/
3. http://localhost/index.php/

Expected result:
----------------
In all three cases a document should be delivered:

1. "bla"
2. "blub"
3. "index.php"

Actual result:
--------------
1. Correctly delivers document.
2. No document is delivered.
3. Correctly delivers document.

Exactly how can we reproduce this? It works just fine for me when I have
this .htaccess file:

RewriteEngine on
RewriteRule ^(.+)/$ index.php?myarg=$1 [L]

So what else do we need?

After rebuilding Apache2 and PHP5-dev on different machines the whole
weekend about 2 million times and wondering why some showed the bug,
some not, I eventually tracked it down to the following simple
configuration setting (*drum roll*):

*** output_buffering ***

To trigger the bug, set "output_buffering = On" or (e.g.)
"output_buffering = 4096", TO BYPASS THE BUG (listen up, bug plagued
Joomla!/Wordpress/etc. users) SET "output_buffering = Off" in your
php.ini. This bypass works for PHP 4 & 5.

Cheers,
rob.

PS: If I extend my testcase to

<?php ob_start(); echo($_GET['myarg']); ob_end_flush(); ?>

with "output_buffering = Off" that still does _not_ trigger the bug.
Maybe that helps.

It isn't that setting. Everything works just fine for me even
when I have output_buffering=4096 (default in php.ini-recommended)

Try making a diff of your php.ini against the "base" php.ini-* found in
the snapshot.

rob@sickbox:~/web/devel/phpbug> diff /usr/local/etc/php.ini-dist
/usr/local/etc/php.ini
94c94
< output_buffering = Off
---
> output_buffering = 4096

:)

So we have same php.ini file in use now. And I still can't reproduce
using your rewrite rules and script. So what else is different?

May be it's platform-depend bug?
I have errors on AMD64/FreeBSD.

I'm having issues on i386/FreeBSD 4.11

For the information/record: I used FreeBSD 5.4 and FreeBSD 6.0 
on i386 hardware.

Same problem on SuSE 9.3 and Apache 2.0.55 and 4.x and 5.x snapshots on
i386.
I've compiled Apache by hand and used the SuSE rpm's but I get the same
error (blank page). I've also tried the php.ini-recommended and
php.ini-dist without changes and it don't work.

With 4.4.0 all works fine but since release of 4.4.1 and later snapshots
(4.x and 5.x) mod_rewrite fails.

FreeBSD 4.11, Apache 2.0.55

Immediately after upgrading the PHP package from ports I get 
blank pages from Gallery integrated into Drupal which is using 
mod_rewrite.  4.4.0 did not have this issue and no other 
config file changes were made.

sniper,

To quickly reproduce the bug on FreeBSD 6.0, I do the following:

1. Install Apache 2.0.55 using FreeBSD ports

2. Install PHP 5.0.5 using FreeBSD ports
--> The bug does _not_ show up. (If I had installed 4.4.1 from ports, it
would)

4. Get a 5-dev snapshot (the last one I got is of 2005-11-06) and do
this:

./configure\
  --enable-versioning\
  --enable-memory-limit\
  --with-layout=GNU\
  --with-config-file-scan-dir=/usr/local/etc/php\
  --disable-all\
  --enable-libxml --with-libxml-dir=/usr/local\
  --enable-spl\
  --with-apxs2=/usr/local/sbin/apxs\
  --prefix=/usr/local\
  i386-portbld-freebsd6.0 &&\
make clean &&\
make &&\
cp libs/libphp5.so /usr/local/libexec/apache2 &&\
/usr/local/etc/rc.d/apache2.sh restart

--> there it is.

The configure arguments are the standard arguments of the FreeBSD build
system, but I do _not_ apply any of the FreeBSD-specific patches, they
deliver (and which got included in the build in step 2).

So, either the bug was introduced after 5.0.5 or one of the patches
(have a look at them here:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/php5/files/) fixes it
(which I personally don't think).

Cheers, Rob.

 --enable-versioning <-- Do you know what that does?

(this has nothing to do with the bug, just note that you're using
configure options you should not use)

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

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.

PHP isn't actually crashing with this bug. The original report doesn't
seem to suggest it's crashing either, I'm not sure why the report title
is as it is. This bug is very easily reproducable (on FreeBSD/PHP 4.4.1
at least) with default installs

The bug simply causes PHP not to output anything in most cases, or
output part of a page in others then stop

This is the only debug output I get:

/root/php-4.4.1/Zend/zend_hash.c(275) :  Freeing 0x0868C2A4 (40 bytes),
script=/
srv/www/htdocs/index.php
Last leak repeated 45 times
/root/php-4.4.1/Zend/zend_execute.c(512) :  Freeing 0x0855441C (12
bytes), scrip
t=/srv/www/htdocs/index.php
/root/php-4.4.1/Zend/zend_opcode.c(295) :  Freeing 0x08535764 (30300
bytes), scr
ipt=/srv/www/htdocs/index.php
/root/php-4.4.1/Zend/zend_operators.c(1068) :  Freeing 0x08554304 (2
bytes), scr
ipt=/srv/www/htdocs/index.php
/root/php-4.4.1/Zend/zend_compile.c(875) :  Freeing 0x085542CC (7
bytes), script
=/srv/www/htdocs/index.php
/root/php-4.4.1/Zend/zend_variables.c(111) : Actual location (location
was relay
ed)
Last leak repeated 13 times
Zend/zend_language_scanner.c(4526) :  Freeing 0x08554294 (7 bytes),
script=/srv/www/htdocs/index.php
Last leak repeated 52 times
Zend/zend_language_scanner.c(4744) :  Freeing 0x0855425C (7 bytes),
script=/srv/
www/htdocs/index.php
Last leak repeated 64 times
Zend/zend_language_scanner.c(4518) :  Freeing 0x08554224 (4 bytes),
script=/srv/
www/htdocs/index.php
Last leak repeated 118 times
Zend/zend_language_scanner.c(4653) :  Freeing 0x085541EC (3 bytes),
script=/srv/
www/htdocs/index.php
Last leak repeated 19 times
/root/php-4.4.1/Zend/zend_opcode.c(230) :  Freeing 0x0855416C (24
bytes), script
=/srv/www/htdocs/index.php
Zend/zend_language_scanner.c(3945) :  Freeing 0x085540C4 (5 bytes),
script=/srv/
www/htdocs/index.php
Last leak repeated 21 times
/root/php-4.4.1/Zend/zend_execute.c(1080) :  Freeing 0x08554084 (12
bytes), scri
pt=/srv/www/htdocs/index.php
Zend/zend_language_scanner.c(4433) :  Freeing 0x086F4704 (28 bytes),
script=/srv
/www/htdocs/index.php
Last leak repeated 7 times
/root/php-4.4.1/Zend/zend_compile.c(1790) :  Freeing 0x08711ECC (13
bytes), scri
pt=/srv/www/htdocs/index.php
/root/php-4.4.1/Zend/zend_variables.c(111) : Actual location (location
was relay
ed)
Last leak repeated 1 time
/root/php-4.4.1/Zend/zend_compile.c(1774) :  Freeing 0x08711DDC (13
bytes), scri
pt=/srv/www/htdocs/index.php
/root/php-4.4.1/Zend/zend_variables.c(111) : Actual location (location
was relay
ed)
Last leak repeated 1 time
Zend/zend_language_scanner.c(4866) :  Freeing 0x0856D684 (2 bytes),
script=/srv/
www/htdocs/index.php
Last leak repeated 3 times
Zend/zend_language_scanner.c(4534) :  Freeing 0x0868D16C (3 bytes),
script=/srv/
www/htdocs/index.php
Last leak repeated 1 time
/root/php-4.4.1/Zend/zend_opcode.c(65) :  Freeing 0x082CAE94 (4 bytes),
script=/
srv/www/htdocs/index.php
/root/php-4.4.1/Zend/zend_compile.c(137) :  Freeing 0x082CAC9C (26
bytes), scrip
t=/srv/www/htdocs/index.php
Zend/zend_language_scanner.c(3096) :  Freeing 0x0868CD2C (84 bytes),
script=/srv
/www/htdocs/index.php
/root/php-4.4.1/ext/mbstring/mbstring.c(1016) :  Freeing 0x0868CCF4 (8
bytes), s
cript=/srv/www/htdocs/index.php
/root/php-4.4.1/Zend/zend_alloc.c(219) : Actual location (location was
relayed)
/root/php-4.4.1/Zend/zend_hash.c(199) :  Freeing 0x0868CCA4 (32 bytes),
script=/
srv/www/htdocs/index.php
Last leak repeated 8 times
/root/php-4.4.1/main/main.c(1520) :  Freeing 0x0868CB1C (44 bytes),
script=/srv/
www/htdocs/index.php
/root/php-4.4.1/Zend/zend_API.c(563) : Actual location (location was
relayed)
/root/php-4.4.1/main/main.c(1519) :  Freeing 0x0856B794 (12 bytes),
script=/srv/
www/htdocs/index.php
/root/php-4.4.1/main/main.c(1502) :  Freeing 0x086964EC (44 bytes),
script=/srv/
www/htdocs/index.php
/root/php-4.4.1/Zend/zend_API.c(563) : Actual location (location was
relayed)
/root/php-4.4.1/main/main.c(1501) :  Freeing 0x086964AC (12 bytes),
script=/srv/
www/htdocs/index.php
/root/php-4.4.1/main/php_variables.c(190) :  Freeing 0x086AFA84 (12
bytes), scri
pt=/srv/www/htdocs/index.php
Last leak repeated 28 times
/root/php-4.4.1/ext/standard/string.c(2451) :  Freeing 0x086AFA34 (26
bytes), sc
ript=/srv/www/htdocs/index.php
Last leak repeated 28 times
/root/php-4.4.1/Zend/zend_hash.c(453) :  Freeing 0x086AC494 (128 bytes),
script=
/srv/www/htdocs/index.php
/root/php-4.4.1/main/main.c(1314) :  Freeing 0x086F40FC (44 bytes),
script=/srv/
www/htdocs/index.php
/root/php-4.4.1/Zend/zend_API.c(563) : Actual location (location was
relayed)
/root/php-4.4.1/main/main.c(1313) :  Freeing 0x0823F4E4 (12 bytes),
script=/srv/
www/htdocs/index.php
/root/php-4.4.1/main/php_variables.c(263) :  Freeing 0x086F4854 (44
bytes), scri
pt=/srv/www/htdocs/index.php
/root/php-4.4.1/Zend/zend_API.c(563) : Actual location (location was
relayed)
Last leak repeated 1 time
/root/php-4.4.1/main/php_variables.c(262) :  Freeing 0x081B8784 (12
bytes), scri
pt=/srv/www/htdocs/index.php
Last leak repeated 1 time
/root/php-4.4.1/main/output.c(444) :  Freeing 0x086AF58C (23 bytes),
script=/srv
/www/htdocs/index.php
/root/php-4.4.1/main/output.c(438) :  Freeing 0x08692CBC (6145 bytes),
script=/s
rv/www/htdocs/index.php
/root/php-4.4.1/Zend/zend_ptr_stack.c(29) :  Freeing 0x0868ED4C (256
bytes), scr
ipt=/srv/www/htdocs/index.php
Last leak repeated 2 times
/root/php-4.4.1/Zend/zend_stack.c(27) :  Freeing 0x0823F364 (256 bytes),
script=
/srv/www/htdocs/index.php
Last leak repeated 6 times

Can this be helpful?

I upgraded from FreeBSD 5.4, Apache 2.0.54 with mod_php 4.3.x to 6.0,
Apache 2.0.55 and mod_php 4.4.1.

After this both Gallery 2 and Drupal 4.6.3 are having difficulties.

At first I thought it might be threading and recompiled apache and
mod_php to be prefork.  Same issue.

What I see is that my site works normally until I try to log in with
drupal, at which point I get the famous 'empty page' and I noticed in my
log file that:

[Thu Nov 10 17:58:47 2005] [notice] child pid 73748 exit signal
Segmentation fault (11)

Like other people I have been using the same configuration files and
have not changed anything during the upgrades.

Yes, I have mod_rewrite enabled.

The ktrace output I got from one of the dying children wasn't helpful,
so I am now trying strace to see if I can get some more information.

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

Updating my PHP4.4.1 port to the _2 revision that Alex did:

- Fix pear pkg-plist
- Increase pear memory limit (requested by amd64)
- Revert apache2handler to the latest working version found in
  PHP 4.4.0, since PHP developers seem not interested in
  fixing the bug with apache2 and mod_rewrite

appears to work now.  I hope the PHP developers bother to take 
some time to look into this as I'm sure others are having the 
problem as well.

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

Hopefully fixed in CVS.
Please test it and confirm.

The problem was solve with the last CVS Version.

Thanks a lot

Gustavo Ledesma.
www.isetec.com.mx

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.