php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #35096 using mod_rewrite with apache2 crashes
Submitted: 2005-11-04 02:49 UTC Modified: 2005-11-22 04:04 UTC
Votes:50
Avg. Score:4.9 ± 0.3
Reproduced:48 of 48 (100.0%)
Same Version:31 (64.6%)
Same OS:13 (27.1%)
From: rob at burningsoda dot com Assigned:
Status: Closed Package: Apache2 related
PHP Version: 5CVS, 4CVS (2005-11-04) (snap) OS: *
Private report: No CVE-ID:
 [2005-11-04 02:49 UTC] rob at burningsoda dot com
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.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-11-06 15:52 UTC] sniper@php.net
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?

 [2005-11-07 12:35 UTC] rob at burningsoda dot com
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.
 [2005-11-07 15:42 UTC] sniper@php.net
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.
 [2005-11-07 15:54 UTC] rob at burningsoda dot com
rob@sickbox:~/web/devel/phpbug> diff /usr/local/etc/php.ini-dist /usr/local/etc/php.ini
94c94
< output_buffering = Off
---
> output_buffering = 4096

:)
 [2005-11-07 15:56 UTC] sniper@php.net
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?
 [2005-11-07 16:50 UTC] sergeym at hoster dot ru
May be it's platform-depend bug?
I have errors on AMD64/FreeBSD.
 [2005-11-07 17:18 UTC] jd at ods dot org
I'm having issues on i386/FreeBSD 4.11
 [2005-11-07 18:25 UTC] remko at elvandar dot org
For the information/record: I used FreeBSD 5.4 and FreeBSD 6.0 
on i386 hardware.
 [2005-11-07 20:17 UTC] free4cd at yahoo dot de
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.
 [2005-11-08 01:26 UTC] Chris at Epler dot net
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.
 [2005-11-08 15:13 UTC] rob at burningsoda dot com
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.
 [2005-11-08 17:47 UTC] sniper@php.net
 --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)

 [2005-11-08 17:49 UTC] sniper@php.net
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.


 [2005-11-08 19:33 UTC] scott at whitetigerphotography dot com
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
 [2005-11-09 17:23 UTC] free4cd at yahoo dot de
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?
 [2005-11-10 21:16 UTC] asmodai at in-nomine dot org
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.
 [2005-11-16 01:00 UTC] php-bugs at lists dot php dot net
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".
 [2005-11-17 19:51 UTC] Chris at Epler dot net
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.
 [2005-11-17 22:12 UTC] tony2001@php.net
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.
 [2005-11-22 03:39 UTC] gledesma at isetec dot com dot mx
The problem was solve with the last CVS Version.

Thanks a lot

Gustavo Ledesma.
www.isetec.com.mx
 [2005-11-22 04:04 UTC] iliaa@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.


 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Fri Apr 18 13:02:15 2014 UTC