php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #48744 Segmentation fault with open_basedir enabled
Submitted: 2009-06-30 16:40 UTC Modified: 2009-08-02 18:04 UTC
Votes:5
Avg. Score:4.6 ± 0.5
Reproduced:5 of 5 (100.0%)
Same Version:5 (100.0%)
Same OS:2 (40.0%)
From: tom at ideaweb dot de Assigned:
Status: Closed Package: Safe Mode/open_basedir
PHP Version: 5.3.0 OS: Linux Debian Etch
Private report: No CVE-ID:
 [2009-06-30 16:40 UTC] tom at ideaweb dot de
Description:
------------
Segmentation fault if the following line is enabled in apache.conf:

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

Maybe i made something wrong or its not a bug in php, because i not 
really understand the debug output, but i hope it helps =)

(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 -1212832064 (LWP 4837)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212832064 (LWP 4837)]
0xb757a7b7 in OnUpdateBaseDir (entry=0x824fba0, 
    new_value=0x83b6398 
"/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=0xb7b593a0, 
mh_arg3=0x0, stage=4) at /www/src/php-5.3.0/main/fopen_wrappers.c:103
103		if (!*p || !**p) {
(gdb) bt
#0  0xb757a7b7 in OnUpdateBaseDir (entry=0x824fba0, 
    new_value=0x83b6398 
"/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=0xb7b593a0, 
mh_arg3=0x0, stage=4) at /www/src/php-5.3.0/main/fopen_wrappers.c:103
#1  0xb75f6d09 in zend_alter_ini_entry_ex (name=0x819a670 
"open_basedir", name_length=13, 
    new_value=0x8228770 
"/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/php-5.3.0/Zend/zend_ini.c:285
#2  0xb75f6b0f in zend_alter_ini_entry (name=0x819a670 "open_basedir", 
name_length=13, 
    new_value=0x8228770 
"/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/php-
5.3.0/Zend/zend_ini.c:243
#3  0xb76a86b6 in apply_config (dummy=0x8228df8) at /www/src/php-
5.3.0/sapi/apache2handler/apache_config.c:197
#4  0xb76a7a73 in php_handler (r=0x837fe30) at /www/src/php-
5.3.0/sapi/apache2handler/sapi_apache2.c:547
#5  0x0807dad7 in ap_run_handler (r=0x837fe30) at config.c:157
#6  0x08080bc7 in ap_invoke_handler (r=0x837fe30) at config.c:372
#7  0x080c8658 in ap_process_request (r=0x837fe30) at 
http_request.c:282
#8  0x080c581e in ap_process_http_connection (c=0x836fd40) at 
http_core.c:190
#9  0x08084a87 in ap_run_process_connection (c=0x836fd40) at 
connection.c:43
#10 0x080f846d in child_main (child_num_arg=<value optimized out>) at 
prefork.c:650
#11 0x080f86a5 in make_child (s=0x813d648, slot=0) at prefork.c:690
#12 0x080f944c in ap_mpm_run (_pconf=0x81380a8, plog=0x8188328, 
s=0x813d648) at prefork.c:966
#13 0x0806b44f in main (argc=135487648, argv=0x836db60) at main.c:740



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-07-01 05:56 UTC] rasmus@php.net
I can't reproduce this.  Where in your apache.conf do you have that line?  As in which config blocks is it inside?
 [2009-07-01 07:33 UTC] tom at ideaweb dot de
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>
 [2009-07-01 17:59 UTC] sjoerd-php at linuxonly dot nl
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.
 [2009-07-01 19:48 UTC] tom at ideaweb dot de
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
 [2009-07-07 17:23 UTC] jani@php.net
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.
 [2009-07-10 14:00 UTC] jleg at nrw dot net

 [2009-07-10 15:50 UTC] tom at ideaweb dot de
Without php.ini the server keeps crashing, but i think with "wrong 
configuration parameters" the server should not crash...
 [2009-07-10 18:26 UTC] jani@php.net
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..
 [2009-07-10 18:46 UTC] tom at ideaweb dot de
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)
 [2009-07-10 22:15 UTC] jani@php.net
Is the backtrace the same?
 [2009-07-15 07:29 UTC] tom at ideaweb dot de
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)
 [2009-07-16 13:08 UTC] jani@php.net
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. 
 [2009-07-17 04:05 UTC] dougcsd at yahoo dot com
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.
 [2009-07-17 10:19 UTC] rs at qcm dot cz

 [2009-07-17 11:37 UTC] rs at qcm dot cz
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.
 [2009-07-19 17:24 UTC] vytas dot LT at gmail dot com
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".
 [2009-07-30 09:13 UTC] starcraftmazter at gmail dot com
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
 [2009-07-31 15:54 UTC] tom at ideaweb dot de
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&#7744;]) 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&#1784;) 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 =(  ...)
 [2009-07-31 16:52 UTC] tom at ideaweb dot de
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! =))
 [2009-07-31 23:05 UTC] jani@php.net
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
 [2009-08-01 09:57 UTC] tom at ideaweb dot de
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....)
 [2009-08-01 10:00 UTC] tom at ideaweb dot de
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 =))
 [2009-08-01 14:56 UTC] rasmus@php.net
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.
 [2009-08-01 15:15 UTC] rasmus@php.net
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
 [2009-08-02 18:04 UTC] tom at ideaweb dot de
Perfect... it works! Segmentation fault is gone with modified 
fopen_wrappers.c. Thx!
 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Fri Apr 18 20:01:57 2014 UTC