I can't reproduce this.  Where in your apache.conf do you have that line?  As in which config blocks is it inside?

Its really strange, because i have several php53 installations without 
any trouble with the same configuration, but only on one dev server it 
crashes. if you cannot reproduce, its not a big deal that you can get 
access to our dev server, there are not secrets and no data...

<VirtualHost *:80>

    ServerAdmin webmaster@ecolint.ch

    ServerName ecodev.ecolint.ch
    ServerAlias ecm.ideaweb.de
    ServerAlias 217.169.129.40

    #ErrorDocument 404 /

    DocumentRoot /var/www/ecolint.ch/dev/ecolint/trunk/admin

    CustomLog /var/www/ecolint.ch/logs/access_log combined
    ErrorLog /var/www/ecolint.ch/logs/error_log

    <Directory /var/www/ecolint.ch/dev/ecolint/trunk/admin/>
        Options -MultiViews -Indexes -Includes +FollowSymlinks
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>

    Alias /mysql/ /var/www/ecolint.ch/mysql/

    <Directory /var/www/ecolint.ch/mysql/>
        Options -MultiViews -Indexes -Includes -FollowSymlinks
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>

    php_admin_flag register_globals off
    php_admin_flag magic_quotes_gpc off
    php_admin_flag magic_quotes_runtime off
    php_admin_value default_charset utf-8
    php_admin_value session.save_path /www/htdocs/ecolint.ch/tmp/
    php_admin_value upload_tmp_dir /www/htdocs/ecolint.ch/tmp/
    php_admin_value open_basedir 
/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/ecol
int.ch/mysql

    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
    RewriteRule .* - [F]

</VirtualHost>

Are you perhaps running a multithreaded Apache server with a non-thread-safe PHP module?

Check "Thread Safety" in phpinfo() and whether you have apache2-mpm-worker or apache2-mpm-prefork.

Thread Safety is disabled (shown in phpinfo()), but i did never 
enabled it on our servers, and we have lot... and i'm using apache2-
mpm-prefork... these default configurations ran never in trouble for 
me, on high traffic sites too, but in this case it crashes on each 
request. =(

./configure \
"--enable-so" \
"--enable-cgi" \
"--enable-info" \
"--enable-rewrite" \
"--enable-usertrack" \
"--enable-deflate" \
"--enable-dav" \
"--enable-unique-id" \
"--enable-dav-fs" \
"--enable-dav-lock" \
"--enable-mime-magic" \
"--enable-proxy" \
"--enable-ssl" \
"--with-ssl=/usr" \
"--prefix=/www/apache/2.2.11"

[...]
checking which MPM to use... prefork
[...]

./configure \
--prefix=/www/prog/php/5.3.0 \
--with-apxs2=/www/apache/2.2.11/bin/apxs \
--with-config-file-path=/www/etc \
--with-iconv=/usr/local \
--with-iconv-dir=/usr/local \
--with-mysqli=/www/prog/mysql/current/bin/mysql_config \
--with-mysql-sock=/www/share/mysql/current/mysqld.sock \
--with-pdo-mysql=/www/prog/mysql/current/ \
--with-mysql=/www/prog/mysql/current/ \
--enable-safe-mode=no \
--enable-discard \
--enable-magic-quotes \
--enable-track-vars \
--with-zlib \
--with-zlib-dir=/usr \
--enable-trans-sid \
--with-openssl=/usr \
--enable-wddx \
--enable-bcmath \
--enable-shmop \
--enable-mhash \
--enable-ftp \
--enable-calendar \
--with-gd \
--with-freetype \
--with-freetype-dir=/usr \
--with-jpeg \
--with-jpeg-dir=/usr \
--enable-exif \
--with-png \
--with-png-dir=/usr \
--enable-mbstring \
--enable-sockets \
--with-mhash=/usr \
--with-ldap=/usr \
--with-kerberos=/usr \
--with-libxml-dir=/usr \
--with-gettext \
--with-xsl=/usr \
--enable-soap \
--with-mcrypt \
--enable-debug

Obvious thing to check is what are the differences in your working installation and this non-working one's php.ini, configure line, loaded modules, apache settings..etc.

Hi,

i just wanted to confirm this behaviour - we recently upgraded one of our development servers from PHP 5.2.9 to 5.3.0, and experienced similar segfaulting. Test script only contains "phpinfo()".
It segfaults one time out of three.

System is a CentOS 5.3, standard httpd (prefork). Updating PHP was the only change. Reverting back to 5.2.9 stops segfaulting, as well as removing the "php_admin_value open_basedir" in apache config.
To build the PHP 5.3.0, the same configure-script as fpr 5.2.x was used - with the exception of including "mysqlnd".

Error msg in log while segfaulting is (note that garbage in "allowed paths"):

PHP Warning:  Unknown: open_basedir restriction in effect. File(<....>/t.php) is not within the allowed path(s): (\?<        \?<     ?g=     ) in Unknown on line 0
PHP Warning:  Unknown: failed to open stream: Operation not permitted in Unknown on line 0

regards, Jan

Without php.ini the server keeps crashing, but i think with "wrong 
configuration parameters" the server should not crash...

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

Just in case this is just another side-effect caused by another bug..

Keeps crashing with php5.3-200907101630 =(

[Fri Jul 10 20:41:45 2009] [notice] child pid 13862 exit signal 
Segmentation fault (11)
[Fri Jul 10 20:41:47 2009] [notice] child pid 13863 exit signal 
Segmentation fault (11)

Is the backtrace the same?

Sorry for the delay, the test server was in use...

Seems to be the same =(

(gdb) run -X -d /www/apache/current/
Starting program: /www/apache/2.2.11/bin/httpd -X -d 
/www/apache/current/
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1212967232 (LWP 27684)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212967232 (LWP 27684)]
0xb755848f in OnUpdateBaseDir (entry=0x824fbb8, 
    new_value=0x83b5070 
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql", 
    new_value_length=82, mh_arg1=0x48, mh_arg2=0xb7b37e80, 
mh_arg3=0x0, stage=4)
    at /www/src/php5.3-200907101630/main/fopen_wrappers.c:103
103		if (!*p || !**p) {
(gdb)

Have you figured out the differences between the working and non-working servers running 5.3 yet? That's propably the only way to debug this. Otherwise, just let this rot. 

Here is more info on this.  

I ran into this earlier while running 5.3 Alpha snapshots.

The Snapshot:  php5.3-200810090430 (Alpha 3) did not seem to have this problem yet, and works ok.  I have reproduced the problem on two machines and multiple operating systems.  I see the scrambled open basedir paths in the apache logs when a simple phpinfo() fails.

Both systems were running Slackware 12.1 (one 32 bit, and one 64 bit) BlueWhite64 for the 12.1 64 bit.

I recently upgraded to Slackware 12.2 on the 32 bit machine to upgrade the libc to a newer version and see if it helped, but the problem persists.

I first saw this problem in php5.3-200903230730, and assumed it was a development bug that would work itself out in time, and simply reverted back.  However the problem has carried over to 5.3.0 release.

I have done a bit of digging and it appears that both PHP and Apache are using pthreads on these machines.  Because of the randomness of when the corruption occurs, I believe this may be related to a threading issue, but I have yet to discover any additional details.

Hello everyone!

I'm experiencing similar problems using PHP 5.3.0 final on 64-bit CentOS with Apache 2.2.3.

I'm not actually getting segfaults but defining "php_admin_value open_basedir /home/webs/" anywhere in httpd.conf results in open_basedir errors that look like these:

Warning: Unknown: open_basedir restriction in effect. File(/home/webs/_devel/public/index2.php) is not within the allowed path(s): (0?û??*) in Unknown on line 0 Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0 

The open_basedir variable value is distorted in a weird way and the string remains the same until Apache is reloaded. Then it changes to a different set of random characters.

From what I've tried disabling all PHP extensions didn't make any difference, the only thing that helps is defining open_basedir in php.ini instead.

I'm running Apache in prefork mode and PHP with Thread Safety disabled.

Ok, I think I've ran into some kind of overflow game here. This is my test PHP setup in httpd.conf:

php_admin_value safe_mode 0
php_admin_value upload_tmp_dir        somepath1_123456
php_admin_value session.save_path     somepath2_123456
php_admin_value open_basedir /home/webs/
php_admin_value include_path  .:/usr/share/misc:/usr/share:/home/webs/.libs:/home/webs/.libs/php-pear
php_admin_value display_errors        On

To be able to see what path is being looked for in open_basedir I'm including a file that is not within the /home/webs directory.

This is the result as expected:
Warning: include_once(): open_basedir restriction in effect. File(/tmp/something) is not within the allowed path(s): (/home/webs/) in /home/webs/_devel/public/index2.php on line 13 Call Stack: 0.0000 616224 1. {main}()

Note that the upload_tmp_dir and session.save_path variables are exactly 16 chars long. Now let's shorten the second one a little bit:

php_admin_value upload_tmp_dir        somepath1_123456
php_admin_value session.save_path     somepath2_12345
php_admin_value open_basedir /home/webs/

And what I got here:
Warning: include_once(): open_basedir restriction in effect. File(/tmp/something) is not within the allowed path(s): (somepath2_12345) in /home/webs/_devel/public/index2.php on line 13 Call Stack: 0.0000 616184 1. {main}() 

Oops? Is that path really what I have set? Let's shorten the next one:

php_admin_value upload_tmp_dir        somepath1_12345
php_admin_value session.save_path     somepath2_12345
php_admin_value open_basedir /home/webs/

And here we go:
Warning: include_once(): open_basedir restriction in effect. File(/tmp/something) is not within the allowed path(s): (somepath1_12345) in /home/webs/_devel/public/index2.php on line 13 Call Stack: 0.0000 616176 1. {main}()

Looks like for three different setups there different strings slip into the open_basedir variable. Silly.

I hope this helps a bit in finding the bug.

I've noticed that one virtual host with open_basedir is working normally. Problem starts, when you using two or more virtual hosts in apache.

Seems to be some sort of memory allocation problem. I have same issue on FreeBSD 7.2-p2 x64 jailed environment. Apache - 2.2.11 from latest FreeBSD ports (2.2.11_7). Error log shows something like:  "PHP Warning:  Unknown: open_basedir restriction in effect. File(/usr/local/www/apache22/data/info.php) is not within the allowed path(s): (\b) in Unknown on line 0" As you see - \b is the allowed paths, and my apache config file contains "php_admin_value open_basedir /usr/local/www/phpMyAdmin:/usr/local/www/apache22/data:/tmp:/manualbuilds/php53/lib/php".

Hello there

I can confirm that I have a very similar issue. I have been running PHP with open_basedir for quite some time. I upgraded to php 5.3.0 recently, previously having ran php 5.2.5. Immediately after installing the newly compiled version, the issues began.

The problem as I experience it, is that the "open_basedir" setting seems to be composed of random, non latin1 characters (displayed as symbols by the browser). I cannot draw any reasons as to which users are affected by this or why, but it does not happen to everyone - it is seemingly random.

I am using CentOS 5.3 with the latest cPanel 11 on CURRENT which manages the open_basedir. I am using Apache 2.2.6.

My compile string is as follows;

'./configure' '--prefix=/usr/local' '--with-apxs2=/usr/local/apache/bin/apxs' '--enable-bcmath' '--enable-calendar' '--enable-exif' '--enable-ftp' '--enable-gd-native-ttf' '--enable-libxml' '--enable-mbstring' '--enable-soap' '--enable-sockets' '--enable-zip' '--with-bz2' '--with-curl=/opt/curlssl/' '--with-curlwrappers' '--with-freetype-dir=/usr' '--with-gd' '--with-gettext' '--with-imap=/opt/php_with_imap_client/' '--with-imap-ssl=/usr' '--with-jpeg-dir=/usr' '--with-kerberos' '--with-libdir=lib64' '--with-libxml-dir=/opt/xml2' '--with-libxml-dir=/opt/xml2/' '--with-mcrypt=/opt/libmcrypt/' '--with-mhash=/opt/mhash/' '--with-openssl-dir=/usr' '--with-pic' '--with-png-dir=/usr' '--with-xpm-dir=/usr' '--with-xsl=/opt/xslt/' '--with-zlib' '--with-zlib-dir=/usr' '--with-openssl=/usr' '--with-mysql' '--with-mysqli' '--with-pgsql' '--with-sqlite=shared' '--enable-pdo=shared' '--with-pdo-sqlite=shared' '--with-pdo-mysql=shared' '--with-pdo-pgsql=shared' '--with-magickwand=/usr/local/bin'

You can check other relevant settings here:
http://liway.com/test.php

For reference, here is the screenshot of the exact error message which one of the accounts is getting, which shows the open_basedir setting being composed of weird characters.
http://img75.imageshack.us/img75/6261/screenshot1a.png
The situation involves phpbb3 trying to include parts of itself, so I am confident that it should be allowed, as it's in the same directory or close directories within a single account home folder.

The second screenshot is of the relevant open_basedir setting in the httpd.conf file. I have checked the settings against those in the virtual hosts of other accounts where open_basedir works without errors, and I can confirm that they are absolutely identical (apart from the actual home directory).
http://img75.imageshack.us/img75/626/screenshot2w.png


Needless to say, this is a very serious issue, as open_basedir is an extremely important security measure for those of us who don't run suPHP, and now it is impossible to use it because of these problems.

I'm available daily for testing, hope this bug report will get some new attention for developers.

Cheers

My problem is, currently its only the first linux server with running php53. Other server needs several modules like ionCube which seems to be not working with, maybe not compatible/supported by the vendor. 

But i tried it with one server... iconCube will be loaded, but php53 throws a lot of errors if open_basedir is enabled. I got errors that iconcube is not in allowed path. A module in "not allowed path"? For ex. 
i defined 3 entries for open_basedir like /var/www:/var/tmp:/var/upload and i get 3 errors that /var/www/iconcube.so, /var/tmp/iconcube.so etc. is not in allowed path. Thats why currently i cannot check the 
issue with the segmentation fault.

Otherwise i "found" a simple server with a lot of wordpress blogs and i installed php53. With open_basedir enabled 70% of requests throw an HTTP 500 (not segmentation fault), but without open_basedir the server 
runs smoothly, realy strange... the same issue but "HTTP 500"?? Or is wordpress/apache/mod_rewrite the troublemaker? I have no idea, how i can debug it. I reversed the installation because the blogs has to 
run...

Thats why i installed a new server in our office and installed one of our running project, with the same configuration and installing procedure like all our other servers (see first post).

Without open_basedir enabled it runs but otherwise 20% of the request fails with the following error message:

Warning: Unknown: open_basedir restriction in effect. File(/var/www/bebees/trunk/bebees/index.php) is not within the allowed path(s): (ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZMaṀ]) in Unknown on line 0

Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0

Fatal error: Unknown: Failed opening required '/var/www/bebees/trunk/bebees/index.php' (include_path='.:/www/prog/php/5.3.0/lib/php') in Unknown on line 0

If i make an erroron purpose, php throws an message as expected for ex.:

Warning: include_once() [function.include-once]: open_basedir restriction in effect. File(/var/www/ideacmf/tags/1_0_4/core/cmf.php) is not within the allowed path(s): (/www/tmp:/var/www/bebees/trunk) in 
/var/www/bebees/trunk/bebees/index.php on line 16

Than i installed the same project which is installed as in my first post, but same result, no segmentation fault:

Warning: Unknown: open_basedir restriction in effect. File(/var/www/ecolint/trunk/admin/index.php) is not within the allowed path(s): (M۸) in Unknown on line 0

Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0

Fatal error: Unknown: Failed opening required '/var/www/ecolint/trunk/admin/index.php' (include_path='.:/www/prog/php/5.3.0/lib/php') in Unknown on line 0

On the test server, which i've reported first, i have no clue what i can do else, because i've never learned/used c/c++ with all its dev tools or how i can provide more information to fixing this issue, maybe 
something with used adaptec driver in kernel, which returns an "unexpected result" which let apache runs in trouble, no idea... Sorry for the information leak =(  ...)

Maybe i'm wrong, if add the "prefix" path where php is installed to 
open_basedir directive, the segmentation fault and the strange "unicode" 
outputs are gone on all my machines (linux+osx)

./configure \
--prefix=/www/prog/php/5.3.0 \

php_admin_value open_basedir 
/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/ecol
int.ch/mysql:/www/prog/php

but... it should be confirmed by others! =))

Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

This is most likely fixed now. See also bug #48880

I installed php5.3-200908010830:

with the "prefix" directory

php_admin_value open_basedir 
/var/www/ecolint.ch/dev:/var/www/ecolint.ch/tmp:/var/www/ecolint.ch/my
sql:/www/prog/php

everything works as expected, but without it

php_admin_value open_basedir 
/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/ecol
int.ch/mysql

it crashes again:

(gdb) run -X
Starting program: /www/apache/2.2.11/bin/httpd -X
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1213593920 (LWP 22640)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1213593920 (LWP 22640)]
0xb74bf52b in OnUpdateBaseDir (entry=0x824fb10, 
    new_value=0x84d3ce8 
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql", 
    new_value_length=82, mh_arg1=0x48, mh_arg2=0xb7a9eee0, 
mh_arg3=0x0, stage=4)
    at /www/src/php5.3-200908010830/main/fopen_wrappers.c:103
103		if (!*p || !**p) {
(gdb) bt
#0  0xb74bf52b in OnUpdateBaseDir (entry=0x824fb10, 
    new_value=0x84d3ce8 
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql", 
    new_value_length=82, mh_arg1=0x48, mh_arg2=0xb7a9eee0, 
mh_arg3=0x0, stage=4)
    at /www/src/php5.3-200908010830/main/fopen_wrappers.c:103
#1  0xb753bb45 in zend_alter_ini_entry_ex (name=0x819a7a0 
"open_basedir", name_length=13, 
    new_value=0x81fad60 
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql", 
    new_value_length=82, modify_type=4, stage=4, force_change=0)
    at /www/src/php5.3-200908010830/Zend/zend_ini.c:291
#2  0xb753b94b in zend_alter_ini_entry (name=0x819a7a0 "open_basedir", 
name_length=13, 
    new_value=0x81fad60 
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql", 
    new_value_length=82, modify_type=4, stage=4) at /www/src/php5.3-
200908010830/Zend/zend_ini.c:249
#3  0xb75ed4fe in apply_config (dummy=0x81fb3e8)
    at /www/src/php5.3-
200908010830/sapi/apache2handler/apache_config.c:197
#4  0xb75ec8bb in php_handler (r=0x8384c18)
    at /www/src/php5.3-
200908010830/sapi/apache2handler/sapi_apache2.c:547
#5  0x0807dad7 in ap_run_handler (r=0x8384c18) at config.c:157
#6  0x08080bc7 in ap_invoke_handler (r=0x8384c18) at config.c:372
#7  0x080c84da in ap_internal_redirect (new_uri=0x8384be8 
"/index.php/contacts/form_contacts_browse/1?", 
    r=0x837fee0) at http_request.c:501
#8  0x080f3f41 in handler_redirect (r=0x837fee0) at mod_rewrite.c:4801
#9  0x0807dad7 in ap_run_handler (r=0x837fee0) at config.c:157
#10 0x08080bc7 in ap_invoke_handler (r=0x837fee0) at config.c:372
#11 0x080c8658 in ap_process_request (r=0x837fee0) at 
http_request.c:282
#12 0x080c581e in ap_process_http_connection (c=0x836fdf0) at 
http_core.c:190
#13 0x08084a87 in ap_run_process_connection (c=0x836fdf0) at 
connection.c:43
#14 0x080f846d in child_main (child_num_arg=<value optimized out>) at 
prefork.c:650
#15 0x080f86a5 in make_child (s=0x813d648, slot=0) at prefork.c:690
#16 0x080f944c in ap_mpm_run (_pconf=0x81380a8, plog=0x8188328, 
s=0x813d648) at prefork.c:966
#17 0x0806b44f in main (argc=135487648, argv=0x836dc10) at main.c:740

the strange output (bug #48880) i will check later....)

i forgot to write:

/var/www/ecolint.ch/dev:/var/www/ecolint.ch/tmp:/var/www/ecolint.ch/mysql

/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/ecolint.ch/mysql

are the same, and will crash too if there is no /www/prog/php..

sorry for confusion =))

There is something very fishy going on.  Your backtrace shows that OnUpdateBaseDir was called with stage=4 and then it shows the segfault at the line that has:

if (!*p || !**p) {

But that was exactly what I fixed when I fixed bug #48880

stage 4 is PHP_INI_STAGE_ACTIVATE and the current code has:

    if (stage == PHP_INI_STAGE_STARTUP || stage == PHP_INI_STAGE_SHUTDOWN || stage == PHP_INI_STAGE_ACTIVATE || stage == PHP_INI_STAGE_DEACTIVATE) {
        /* We're in a PHP_INI_SYSTEM context, no restrictions */
        *p = new_value;
        return SUCCESS;
    }

    /* Otherwise we're in runtime */
    if (!*p || !**p) {
        /* open_basedir not set yet, go ahead and give it a value */
        *p = new_value;
        return SUCCESS;
    }

So I don't see how a call to OnUpdateBaseDir with stage=4 could have gotten to that condition if you are indeed running the latest code.  Please check main/fopen_wrappers.c line 96 and make sure it has the check for PHP_INI_STAGE_ACTIVATE there.

Aha, I just checked that snapshot you said you used.  It does not have my fix yet.  Mystery solved, I hope.

You can make this one-line change manually in your code to check it:

http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/main/fopen_wrappers.c?r1=282359&r2=286602&pathrev=286602

Perfect... it works! Segmentation fault is gone with modified 
fopen_wrappers.c. Thx!