Just to be sure you're not loading any php.ini files, try this:

(gdb) run -n -r 'var_dump(defined("foo"));'

And you could also try to see what valgrind has to say about it:

# USE_ZEND_ALLOC=0 valgrind --leak-check=yes php -n -r 'var_dump(defined("foo"));'

> Just to be sure you're not loading any php.ini files, try this:
> (gdb) run -n -r 'var_dump(defined("foo"));'
Fails with the same symptoms.

> And you could also try to see what valgrind has to say about it:
> # USE_ZEND_ALLOC=0 valgrind --leak-check=yes php -n -r
> 'var_dump(defined("foo"));'
If you gave me valgrind for ia64 I'd happily do that. ;)

> checking for a supported CPU... no (ia64)
> configure: error: Unsupported host architecture. Sorry

From the looks of it, you have more problems than just PHP here. Not only PHP breaks but also GDB. How about you try get the basic tools working before trying PHP? :)

erm...

[29 Oct 11:15pm UTC] jani@php.net 
Not only PHP breaks but also GDB.

Tell me plz how you guessed that GDB is broken. Just valgrind is not 
available on ia64 architecture but gdb works fine.

[8 Oct 7:24pm UTC] hoffie at gentoo dot org
As soon as debugging symbols are enabled (CFLAGS=-g or
./configure --enable-debug) the problem disappears, that's why I'm
unable to provide a useful backtrace.

Notice that the _problem disappears_.

Yes, I admit that above gdb output shows some strangeness, but well -- that's a gdb problem, not generally software being broken on that system. Upgrading gdb resolved that problem and here goes the new backtrace (using 5.2.5RC2 now):

(gdb) r -n -r 'var_dump(defined("foo"));'

Starting program: /tmp/php-5.2.5RC2/sapi/cli/php -n -r 'var_dump(defined("foo"));'

Program received signal SIGSEGV, Segmentation fault.
_zval_ptr_dtor (zval_ptr=0x60000ffffff3ebd0)
    at /tmp/php-5.2.5RC2/Zend/zend_execute_API.c:412
412             (*zval_ptr)->refcount--;
(gdb) bt
#0  _zval_ptr_dtor (zval_ptr=0x60000ffffff3ebd0)
    at /tmp/php-5.2.5RC2/Zend/zend_execute_API.c:412
#1  0x4000000000298a80 in zend_do_fcall_common_helper_SPEC (
    execute_data=0x60000ffffff3ec50)
    at /tmp/php-5.2.5RC2/Zend/zend_execute.h:155
#2  0x4000000000297200 in execute (op_array=0x60000000000c86e0)
    at /tmp/php-5.2.5RC2/Zend/zend_vm_execute.h:92
#3  0x4000000000228800 in zend_eval_string (str=<value optimized out>, 
    retval_ptr=0x0, string_name=0x400000000041fd10 "Command line code")
    at /tmp/php-5.2.5RC2/Zend/zend_execute_API.c:1171
#4  0x4000000000228c10 in zend_eval_string_ex (
    str=0x60000ffffff3f740 "var_dump(defined(\"foo\"));", retval_ptr=0x0, 
    string_name=0x400000000041fd10 "Command line code", handle_exceptions=1)
    at /tmp/php-5.2.5RC2/Zend/zend_execute_API.c:1205
#5  0x40000000003a2130 in main (argc=Cannot access memory at address 0x10
)
    at /tmp/php-5.2.5RC2/sapi/cli/php_cli.c:1179

This looks like a broken binary, I've seen similar problems on SPARC with GCC 3.x unable to generate working PHP executable.
Try newer/other GCC version.

We are not using gcc-3.x, but gcc-4.1(.2). Anyway, I've tried with 4.2.0 (as it was already installed) and it fails for the same reasons. I'm going to try 4.2.2, I can probably give you results later.

Still reproducable with gcc-4.2.2 and php-5.2.5 (final).

Can you reproduce this with any linux distro on that machine?

I've only tried Gentoo and Debian so far, but I think this should be sufficient. If it fails on two distros and previous versions of php worked (and still work) then it's likely that it is a bug which got introduced with php-5.2, isn't it?

If you still want me to try it on another distro, please point me to some resource to easily install one (like Debians debootstrap).

Same issue here with php-5.2.6 on ia64 (SGI Prism w SLES 9 SP3) using gcc-4.2.4 + binutils-2.18.0.

> As soon as debugging symbols are enabled (CFLAGS=-g or
> ./configure --enable-debug) the problem disappears ...

Issue appears from my rudimentary tests to be due to compiler optimizations, debug symbols have no bearing on the issue

Compiled with CFLAGS=-O0 CXXFLAGS=-O0 no segfault occurs.
Compiled with CFLAGS=-O1 CXXFLAGS=-O1 no segfault occurs.

So whatever the issue is, it is exposed by one/some of the 27 -O2 gcc optimizations.

Even if some change between PHP versions is causing this, it's only happening on ia64, so it might as well be a bug in the compiler. Have you tried more recent GCC version..?

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

Same issue with:
* Sun UltraSparc
* php-5.2.8
* gcc 4.3 (debian stable, lenny)
* default CFLAGS

(gdb) run -n -r 'var_dump(defined("foo"));'

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf7fcc6b0 (LWP 29465)]
0x002ceb88 in _zval_ptr_dtor (zval_ptr=0xffee16f4) at /tmp/src/php-
5.2.8/Zend/zend_execute_API.c:412
412             (*zval_ptr)->refcount--;

Has anyone had a look at this in the recent years?