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.

I'll keep trying generate a backtrace for httpd, but gdb doesn't like that very much. Since I can't stop our production server, I have create an exact duplicate of httpd.conf and name it httpd-debug.conf and simply change the Listen directive and my VirtualHost.

I launch httpd directly from command line like this:

/usr/local/sbin/httpd -X -f /usr/local/etc/apache2/httpd-debug.conf

And the server start ok, and crash as expected when I enter a directory with open_basedir defined.

But I can't manage to start it via gdb, here's what happen:

[root@entrepot apache2]# gdb /usr/local/sbin/httpd
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)...
(gdb) run -X -f /usr/local/etc/apache2/httpd-debug.conf
Starting program: /var/bd/pol/usr/local/sbin/httpd -X -f /usr/local/etc/apache2/httpd-debug.conf
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...gdb in realloc(): error: junk pointer, too high to make sense
Abort trap: 6 (core dumped)
[root@entrepot apache2]#

I'm kinda lost right now. I'll see if I can rebuild PHP with --enable-debug

Well, if that can help.. PHP with --enable-debug and no extension doesn't crash if open_basedir is defined. I'll have to test this with --disable-debug.

I'm buidling the extensions we use for the debug version and see if I can reproduce the crash.

Ok, I wasn't able to generate a backtrace even if I rebuild Apache and PHP with debug option, I can't get a core file. Anyway, like I said earlier, PHP without extionsion doesn't crash if open_basedir is defined, but as soon as I build the following extentions, I receive a Bus error from httpd:

php5-bcmath-5.2.1_2 The bcmath shared extension for php
php5-bz2-5.2.1_2    The bz2 shared extension for php
php5-calendar-5.2.1_2 The calendar shared extension for php
php5-ctype-5.2.1_2  The ctype shared extension for php
php5-dom-5.2.1_2    The dom shared extension for php
php5-extensions-1.1 A "meta-port" to install PHP extensions
php5-gd-5.2.1_2     The gd shared extension for php
php5-gettext-5.2.1_2 The gettext shared extension for php
php5-iconv-5.2.1_2  The iconv shared extension for php
php5-imap-5.2.1_2   The imap shared extension for php
php5-mbstring-5.2.1_2 The mbstring shared extension for php
php5-mcrypt-5.2.1_2 The mcrypt shared extension for php
php5-mhash-5.2.1_2  The mhash shared extension for php
php5-mysql-5.2.1_2  The mysql shared extension for php
php5-mysqli-5.2.1_2 The mysqli shared extension for php
php5-odbc-5.2.1_2   The odbc shared extension for php
php5-pcre-5.2.1_2   The pcre shared extension for php
php5-pdo-5.2.1_2    The pdo shared extension for php
php5-pdo_sqlite-5.2.1_2 The pdo_sqlite shared extension for php
php5-posix-5.2.1_3  The posix shared extension for php
php5-session-5.2.1_2 The session shared extension for php
php5-simplexml-5.2.1_2 The simplexml shared extension for php
php5-spl-5.2.1_2    The spl shared extension for php
php5-sqlite-5.2.1_2 The sqlite shared extension for php
php5-tidy-5.2.1_2   The tidy shared extension for php
php5-tokenizer-5.2.1_2 The tokenizer shared extension for php
php5-xml-5.2.1_2    The xml shared extension for php
php5-xmlreader-5.2.1_2 The xmlreader shared extension for php
php5-xmlwriter-5.2.1_2 The xmlwriter shared extension for php
php5-zlib-5.2.1_2   The zlib shared extension for php
phpMyAdmin-2.9.0.1  A set of PHP-scripts to manage MySQL over the web
pecl-filter-0.11.0  PHP extension for safely dealing with input parameters
pecl-hash-1.3       HASH Message Digest Framework for PHP
pecl-json-1.2.1     PHP extension for JSON (JavaScript Object Notation) seriali
pecl-pdflib-2.1.2   A PECL extension to create PDF on the fly

I did exactly what was written on this page, http://bugs.php.net/bugs-generating-backtrace.php, but no core file and gdb can't stand httpd so no backtrace. Any help will be most welcome.

Thx

Please check if valgrind is able to find something there.

Well, the portage of Valgrind under FreeBSD 6.1 is only for i386 and it complains because I'm on a amd64. So I can't get valgrind to compile. I'll try the source directly from http://valgrind.org/, they saids it support amd64. Stay tune!

I should I have read more before posting my last comment, seems like the FreeBSD port only support i386 and the amd64 support is only for Linux right now.

Guess I'll have to forget about open_basedir for now :(

Try rebuilding PHP with --disable-debug and CFLAGS="-O0 -g".
Btw, what GCC version do you use?

We finaly found a machine on which we can reproduce the error. I'll compile PHP as you recommened. Three servers running FreeBSD 6.1, with the lastest patchs an all, all running on 64bits CPU. Two servers are running with 2x AMD64 Opteron Processor 248 (both crash with open_basedir) and one running with AMD64 Athlon Dual Core (doesn't crash with open_basedir).

I'll try to run httpd under gdb again, I want that backtrace ;)

Well, I compile PHP with --disable-debug and CFLAGS="-O0 -g", can't get a BT. I compile it with --enable-debug and CFLAGS="-O0 -g" again, no BT. I even recompile httpd with either WITHDEBUG=yes and CFLAGS="-O0 -g" still can get a BT. I still can get httpd to run in gdb :

gdb in realloc(): error: junk
pointer, too high to make sense
Abort trap: 6 (core dumped)

I'll try to know at least what is the problematic extension that cause httpd to crash when open_basedir is defined (see comment on [26 Feb 7:12pm UTC]).

Looks like the session extension is the root of the crash. We try every extionsions alone, and only session crashed httpd. I know it would be great if I was able to get that damn BT but I hope this new info can help to find a solution to this problem. If you you have any idea to fix this or new ways to get a BT, please let me know.

Thx.

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

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