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.

make test

Build complete.
(It is safe to ignore warnings about tempnam and tmpnam).

Segmentation Fault
make: [test] Error 139 (ignored)
trapdoor:/opt/src/php/php5.2-200702222130 #  gdb ./sapi/cli/php
GNU gdb 6.3
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 "sparc-sun-solaris2.10"...
(gdb) set args run-tests.php
(gdb) run
Starting program: /opt/src/php/php5.2-200702222130/sapi/cli/php run-tests.php
warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 00000074
warning: Lowest section in /lib/libdl.so.1 is .dynamic at 00000094

Program received signal SIGSEGV, Segmentation fault.
_zval_ptr_dtor (zval_ptr=0x3d6748)
    at /opt/src/php/php5.2-200702222130/Zend/zend_execute_API.c:412
412             (*zval_ptr)->refcount--;
(gdb) bt
#0  _zval_ptr_dtor (zval_ptr=0x3d6748)
    at /opt/src/php/php5.2-200702222130/Zend/zend_execute_API.c:412
#1  0x002892e0 in zend_do_fcall_common_helper_SPEC (execute_data=0xffbfbb4c)
    at zend_execute.h:155
#2  0x002791f0 in execute (op_array=0xffbff110) at zend_vm_execute.h:92
#3  0x00259780 in zend_execute_scripts (type=-2115502080, retval=Variable "retval" is not available.
)
    at /opt/src/php/php5.2-200702222130/Zend/zend.c:1135
#4  0x00214d14 in php_execute_script (primary_file=0x81e80000)
    at /opt/src/php/php5.2-200702222130/main/main.c:1787
#5  0x002e51b0 in main (argc=-2115502080, argv=0x91d0203a)
    at /opt/src/php/php5.2-200702222130/sapi/cli/php_cli.c:1127
(gdb) quit

What kind of GCC did you use?

gcc 4.1.1, built from scratch a couple of days ago.

Try with GCC 4.1.2, it's working fine here on Solaris 9.

No joy.  Rebuilt latest snap version (5.2-200702231530) with gcc 4.1.2.  Still getting seg fault on self-test on both Solaris 9 and 10 SPARC servers.  Also tried minimal config to eliminate possible effects of supplemental packages:

./configure --prefix=/opt \
            --with-config-file-path=/opt/apache/conf \
            --localstatedir=/var/run \
            --with-libxml-dir=/opt

Still barfing.  Traceback on latest build same as before (with exception of absolute address values).

Cannot reproduce.

Don't know if this helps, but I added --disable-inline-optimization to the configure parms; "make test" now gets a little further:

(gdb) run
Starting program: /opt/src/php/php5.2-200702231530/sapi/cli/php run-tests.php
warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 00000074
warning: Lowest section in /lib/libdl.so.1 is .dynamic at 00000094

=====================================================================
CWD         : /opt/src/php/php5.2-200702231530
PHP         : sapi/cli/php 
PHP_SAPI    : cli
PHP_VERSION : 5.2.2-dev
ZEND_VERSION: 2.2.0
PHP_OS      : SunOS - SunOS trapdoor 5.10 Generic_118833-24 sun4u
INI actual  : /opt/src/php/php5.2-200702231530
More .INIs  : 
Extra dirs  : 
=====================================================================

Program received signal SIGSEGV, Segmentation fault.
0x002570c8 in _zval_ptr_dtor (zval_ptr=0xffbfb750)
    at /opt/src/php/php5.2-200702231530/Zend/zend_execute_API.c:412
412             (*zval_ptr)->refcount--;
(gdb) bt
#0  0x002570c8 in _zval_ptr_dtor (zval_ptr=0xffbfb750)
    at /opt/src/php/php5.2-200702231530/Zend/zend_execute_API.c:412
#1  0x00259448 in zend_call_function (fci=0xffbfb7d8, fci_cache=Variable "fci_cache" is not available.
)
    at zend_execute.h:155
#2  0x0019e65c in array_user_compare (a=0x64af70, b=Variable "b" is not available.
)
    at /opt/src/php/php5.2-200702231530/ext/standard/array.c:592
#3  0x0027b854 in zend_qsort (base=Variable "base" is not available.
)
    at /opt/src/php/php5.2-200702231530/Zend/zend_qsort.c:83
#4  0x002719b8 in zend_hash_sort (ht=0x621318, 
    sort_func=0x27b75c <zend_qsort>, compar=0x19e5a4 <array_user_compare>, 
    renumber=1, tsrm_ls=0x3ed738)
    at /opt/src/php/php5.2-200702231530/Zend/zend_hash.c:1275
#5  0x00198170 in zif_usort (ht=Variable "ht" is not available.
)
    at /opt/src/php/php5.2-200702231530/ext/standard/array.c:660
#6  0x0028a2b8 in zend_do_fcall_common_helper_SPEC (execute_data=0xffbff170, 
    tsrm_ls=0x3ed738) at zend_vm_execute.h:200
#7  0x00293804 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xffbff170, 
    tsrm_ls=0x3ed738) at zend_vm_execute.h:1681
#8  0x00289ae8 in execute (op_array=0x3fc678, tsrm_ls=0x3ed738)
    at zend_vm_execute.h:92
#9  0x0026603c in zend_execute_scripts (type=8, tsrm_ls=0x3ed738, retval=Variable "retval" is not available.
)
    at /opt/src/php/php5.2-200702231530/Zend/zend.c:1135
---Type <return> to continue, or q <return> to quit---
#10 0x0021805c in php_execute_script (primary_file=0xffbff8dc, 
    tsrm_ls=0x3ed738) at /opt/src/php/php5.2-200702231530/main/main.c:1787
#11 0x00306494 in main (argc=2, argv=0xffbff9e4)
    at /opt/src/php/php5.2-200702231530/sapi/cli/php_cli.c:1127
(gdb)

An explanation of sorts: I've found that multiple sets of libraries and header files are clashing, specifically for pcre, openssl, libxml, and zlib (perhaps others).  Despite specifying paths in "configure" for the latest versions in /opt, the configure script is not consistently applying that path as it checks for these packages and builds compiler options.  Even worse, Solaris 10 now comes with a number of (outdated) versions of these as well, and portions of those are getting stirred into the mix.

An example of the problem: specifying --with-openssl-dir=/opt results in configure not finding the necessary header files.  I find that line 20825 of the configure script is replacing the supplied path with hardcoded references to /usr/local, et al.  Manually adding /opt to that line solves the header location problem, but the compiler is still reporting large numbers of warnings about mismatched openssl variables.

Another example: specifying --with-libxml2-dir=/opt is not sufficient to keep configure from finding /usr/bin/xml2-config and complaining that the version reported there is too old (big surprise).  It should be picking up the xml2-config in /opt/bin.

With a LOT of manual tweaking, I am able to get "make test" to complete without a sementation fault, but it is still reporting over 50 tests failing.  At this point I am not comfortable installing this on a production server.

>--with-openssl-dir=/opt
This option is used with FTP and SNMP extensions to help them to find OpenSSL.
Are you really compiling FTP and SNMP? I suspect no.

For ext/openssl you need to specify --with-openssl (and --with-openssl-dir is not reaquired in this case).
The "/opt" prefix means that OpenSSL libraries are in /opt/lib/ and headers in /opt/include/. 
Is this correct path? I suspect no.

> The "/opt" prefix means that OpenSSL libraries are in 
> /opt/lib/ and headers in /opt/include/. 
> Is this correct path? I suspect no.

Yep, that is exactly where openssl and the rest of the add-on packages have installed their libraries and header files.

By disabling or removing various packages from the configure parms (openssl, sqlite, readline, iconv), I am finally able to work down to 20 failed self-tests under Solaris 10 and 10 failed tests under Solaris 9, most of which are related to date/time functions.  At this point, I'll consider my original bug report of segmentation faults to be resolved, although obviously there are other, more profound problems going on here.

Thanks for your help.

>At this point, I'll consider my original bug report of
>segmentation faults to be resolved

Ok, thanks.
I don't think a library clash is PHP problem, though.

Two follow up notes:

PHP 4.1.1 compiles on both servers with the same configurations and tests out with no problems.

The solution in bug #40507 completely resolved the problems noted here.  Note that the gcc folks recommend the '-fno-strict-aliasing' flag over the '-fwrapv' flag.