segfault occurs during apache config analyse.

If config doesnt have any php_flag, php_value,... apache starts and works as expected.

I have the same problem on Solaris 11 (express) i86pc. I'm not sure about ZTS mode (I have NOT set --enable-maintainer-zts)

I have compiled php-5.4 (various versions, the latest one being 5.4.0RC4) with the following configure flags:
--with-apxs2=/usr/local/apache2/bin/apxs --with-openssl=/usr/local/ssl --with-openssl-dir=/usr/local/ssl --with-zlib --enable-sockets --enable-shared=yes --enable-static=yes --prefix=/usr/local/apache2/php --enable-calendar --disable-ftp --with-mysql=/usr/local/mysql --with-imap=/usr/local/imap --with-imap-ssl=/usr/local/ssl --enable-flatfile --without-recode --disable-ipv6 --with-mysql-sock=/var/run/mysql/mysql.sock --with-gettext=/opt/csw --enable-libxml --with-db4=/usr/local/BerkeleyDB

Builds and installs fine.

But during apache (2.2.21) startup, it segfaults and dumps core:
# /usr/local/svc/init.d/apache2 restart
Restarting Apache2 httpd ... 
/usr/local/apache2/bin/apachectl: line 80: 17568: Memory fault(coredump)

In fact, uncommenting all php_admin_value lines from apache config file, apache starts normally.

When compiling and installing 5.3.6 with the same configure options, the problem does not occur.

Just tried with 5.3.9RC4, and the problem does not occur. Seems to be something in 5.4

hmm, the problem is when the real_value_hnd is called, the signal_startup has not 
been called yet...

This bug has been fixed in SVN.

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

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

I tried php5.4-201201041430.tar.bz2, and the problem persists (Solaris i86pc):

# /usr/local/apache2/php/bin/php --version
PHP 5.4.0RC5-dev (cli) (built: Jan  4 2012 16:32:14) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

# ls -l /usr/local/apache2/modules/
total 40760
-rw-r--r--   1 root     root        9084 Oct 29 12:14 httpd.exp
-rwxr-xr-x   1 root     root     20803576 Jan  4 16:32 libphp5.so

# /usr/local/svc/init.d/apache2 start
Creating Runtime directory /var/run/apache2
Starting Apache2 httpd ... 
/usr/local/apache2/bin/apachectl: line 80: 25146: Memory fault(coredump)

can you give me the backtrace?  and btw, did you build that from a pure 
environ(make clean, make install).

Yes, the build is always from a pristine source directory (scripted).

I'm sorry to admit that I do not know how to produce a meaningful backtrace. I have the core file and gdb installed on the machine, yet not in the environment (solaris zone) where apache runs. Could you give a pointer on how to produce a helpful backtrace?

OK, managed to get gdb into the zone:

# gdb /usr/local/apache2/bin/httpd
GNU gdb 6.8
...
This GDB was configured as "i386-pc-solaris2.11"...
(gdb) run -X 
Starting program: /usr/local/apache2/bin/httpd -X
warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 00000074
warning: Lowest section in /lib/libdl.so.1 is .dynamic at 00000074
warning: Lowest section in /lib/librt.so.1 is .dynamic at 00000074
warning: Lowest section in /lib/libthread.so.1 is .dynamic at 00000074

Program received signal SIGSEGV, Segmentation fault.
0xfe8956bb in mutex_lock_impl () from /lib/libc.so.1
(gdb) bt
#0  0xfe8956bb in mutex_lock_impl () from /lib/libc.so.1
#1  0xfe895938 in pthread_mutex_lock () from /lib/libc.so.1
#2  0xfe14088d in tsrm_mutex_lock (mutexp=0x0) at /opt/build.d/php-5/tmp/php5.4-201201041430/TSRM/TSRM.c:391
#3  0xfe140e85 in ts_resource_ex (id=0, th_id=0x0) at /opt/build.d/php-5/tmp/php5.4-201201041430/TSRM/TSRM.c:391
#4  0xfe1c3538 in _zend_hash_add_or_update (ht=0x8267cc8, arKey=0x8267cf0 "open_basedir", nKeyLength=13, pData=0x8047894, nDataSize=12, pDest=0x0, flag=1)
    at /opt/build.d/php-5/tmp/php5.4-201201041430/Zend/zend_hash.c:617
#5  0xfe280bbe in real_value_hnd (dummy=0x8267cc8, name=0x8267cf0 "open_basedir", value=0x8267d00 "/data/web/markus:/usr/local/apache2/php/lib/php", status=4)
    at /opt/build.d/php-5/tmp/php5.4-201201041430/sapi/apache2handler/apache_config.c:73
#6  0x0808fa2a in invoke_cmd (cmd=0xfe560cf0, parms=0x8047c70, mconfig=0x8267cc8, args=0x81a1656 "") at config.c:316
#7  0x08267cc8 in ?? ()
#8  0x08267cf0 in ?? ()
#9  0x08267d00 in ?? ()
#10 0x00000004 in ?? ()
#11 0x00000000 in ?? ()

Thanks for the patch.

Works for me, httpd.worker + php 5.4.0RC5-dev ZTS 201201041830.
(solaris bug seems another issue)

seems there is something wrong in solaris .. re-open

Is there any further information that I can provide to help track this down?

sorry, kind of buzy these days, I will look at this in 1 or 2 days, thanks

@public are you sure your backtrace is simple copy&paste?  there is two strange 
lines:
#2  0xfe14088d in tsrm_mutex_lock (mutexp=0x0) at /opt/build.d/php-5/tmp/php5.4-
201201041430/TSRM/TSRM.c:391
#3  0xfe140e85 in ts_resource_ex (id=0, th_id=0x0) at /opt/build.d/php-
5/tmp/php5.4-201201041430/TSRM/TSRM.c:391

both of them are in line 391.

Yes, this is exactly as it is displayed by gdb. I still have the console open, and the output is what I have pasted. Strange, now that you mention it...

fwiw, here's file and linkeage info:

# file /usr/local/apache2/modules/libphp5.so 
/usr/local/apache2/modules/libphp5.so:  ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped
# ldd /usr/local/apache2/modules/libphp5.so 
        libcrypt.so.1 =>         /usr/lib/libcrypt.so.1
        libc-client.so =>        /usr/local/imap/lib/libc-client.so
        libresolv.so.2 =>        /lib/libresolv.so.2
        librt.so.1 =>    /lib/librt.so.1
        libmysqlclient.so.18 =>  /usr/local/mysql/lib/libmysqlclient.so.18
        libcrypto.so.1.0.0 =>    /usr/local/ssl/lib/libcrypto.so.1.0.0
        libssl.so.1.0.0 =>       /usr/local/ssl/lib/libssl.so.1.0.0
        libpam.so.1 =>   /lib/libpam.so.1
        libintl.so.8 =>  /opt/csw/lib/libintl.so.8
        libdb-4.7.so =>  /opt/csw/lib/libdb-4.7.so
        libz.so =>       /opt/csw/lib/libz.so
        libm.so.2 =>     /lib/libm.so.2
        libnsl.so.1 =>   /lib/libnsl.so.1
        libsocket.so.1 =>        /lib/libsocket.so.1
        libxml2.so.2 =>  /lib/libxml2.so.2
        libc.so.1 =>     /lib/libc.so.1
        libgcc_s.so.1 =>         /opt/csw/lib/libgcc_s.so.1
        libgen.so.1 =>   /lib/libgen.so.1
        libmd.so.1 =>    /lib/libmd.so.1
        libthread.so.1 =>        /lib/libthread.so.1
        libz.so.1 =>     /lib/libz.so.1
        libdl.so.1 =>    /lib/libdl.so.1
        libiconv.so.2 =>         /opt/csw/lib/libiconv.so.2
        libpthread.so.1 =>       /lib/libpthread.so.1
        libmp.so.2 =>    /lib/libmp.so.2

weird, does anyone else can reproduce this with the latest snap yet?

Hi all

After a couple of upgrades:
- solaris from express to 11.0
- apache from 2.2.21 to 2.2.22

I can now get the latest snapshot 201202281230 working!

[Tue Feb 28 14:20:59 2012] [notice] Apache/2.2.22 (Unix) PHP/5.4.0RC9-dev mod_ssl/2.2.22 OpenSSL/1.0.0g configured -- resuming normal operations

Apache does not segfault anymore, event though there are php_admin_values throughout all config files.

So, at the moment, I don't know why, but it works for me.