Wow, that sounds like an insanely complex piece of PHP code.  It sounds like you are indeed hitting some odd bug, but unless you can come up with a way for us to reproduce it on our dev boxes I don't see how we can help you.

I have created some example code to illustrate this bug.  It's available at:

  http://www.lariatcentral.com/test1.tar.gz

There are two cases in the file:
   * one consistantly causes corruption and often a crash
   * one consistantly always causes a segmentation fault

There are several classes in this package.  It may have been possible to make this example more concise but I haven't had any success doing so.  There is also a file called backtrace.txt that shows the three main crashes I am seeing.

I believe we are tickling this bug in a much more subtle way in our code.  If we knew why this was happening we could change the code to "not do that", PHP should not be segfaulting or corrupting data.  

I have tested this example on two servers and it worked (corrupted/crashed) on both.  You might try fiddling with the set_time_limit() to change the way the corruption is visible.

Let me know how I can assist you further.  Thanks.

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

And use EXACTLY this configure line:

./configure \
--prefix=/usr/local/php_4.3.1 \
--with-apxs=/usr/local/apache/bin/apxs \
--enable-bcmath  \
--enable-gd-native-ttf  \
--with-gd  \
--with-ttf  \
--enable-calendar \
--with-mysql  \
--with-openssl  \
--with-iconv  \
--enable-xml  \
--with-pgsql=/usr/local/pgsql-7.3 \
--with-mcrypt \
--with-curl \
--with-zip \
--enable-ftp \
--with-zlib-dir=/usr \
--enable-debug

Also, disable Zend optimizer and generate the GDB backtrace
as instructed here:

http://bugs.php.net/bugs-generating-backtrace.php

And DO NOT ADD THE FULL backtrace here!!
only the relevant part of it, usually the 15-20 first lines.

Here is the one from crash1.php in my examples:

Program received signal SIGSEGV, Segmentation fault.
0x40415404 in zval_add_ref (p=0x8190a60) at /usr/local/src/php4-STABLE-200304240730/Zend/zend_variables.c:85
85              (*p)->refcount++;
(gdb) bt
#0  0x40415404 in zval_add_ref (p=0x8190a60) at /usr/local/src/php4-STABLE-200304240730/Zend/zend_variables.c:85
#1  0x4041dd38 in zend_hash_copy (target=0x81970dc, source=0x8193e5c, pCopyConstructor=0x404153fc <zval_add_ref>, tmp=0xbfffcbd4, size=4) at /usr/local/src/php4-STABLE-200304240730/Zend/zend_hash.c:789
#2  0x40415651 in _zval_copy_ctor (zvalue=0x81889d4, __zend_filename=0x404e8180 "/usr/local/src/php4-STABLE-200304240730/Zend/zend_execute.c", __zend_lineno=1795)
    at /usr/local/src/php4-STABLE-200304240730/Zend/zend_variables.c:137
#3  0x4042b131 in execute (op_array=0x8162cc4) at /usr/local/src/php4-STABLE-200304240730/Zend/zend_execute.c:1795
#4  0x40417384 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/src/php4-STABLE-200304240730/Zend/zend.c:864
#5  0x403db91e in php_execute_script (primary_file=0xbffff8c8) at /usr/local/src/php4-STABLE-200304240730/main/main.c:1637
[...]
(gdb) frame 3
#3  0x4042b131 in execute (op_array=0x8162cc4) at /usr/local/src/php4-STABLE-200304240730/Zend/zend_execute.c:1795
1795                                                            zval_copy_ctor(varptr);
(gdb) print (char *)(executor_globals.function_state_ptr->function)->common.function_name
$1 = 0x0
(gdb) print (char *)executor_globals.active_op_array->function_name
$2 = 0x0
(gdb) print (char *)executor_globals.active_op_array->filename
$3 = 0x8162fb4 "/usr/local/apache/lariat/lariat2/test/test1/crash1.php"

Was this with the configure line I told you to use?

Yes, I copied and pasted the configure line.

The corrupt1.php in the examples I provided also creates this backtrace fairly consistently.  This only happens after at least two reloads and sometimes requires me to close my browser and revisit the index.php page then corrupt1.php page while the same apache/php thread is running in gdb.

Program received signal SIGSEGV, Segmentation fault.
0x400ee1c3 in memcpy () from /lib/libc.so.6
(gdb) bt
#0  0x400ee1c3 in memcpy () from /lib/libc.so.6
#1  0x40402c53 in _mem_block_check (ptr=0x81792bc, silent=0, __zend_filename=0x404e64a0 "/usr/local/src/php4-STABLE-200304240730/Zend/zend_opcode.c", __zend_lineno=159, 
    __zend_orig_filename=0x404e68c0 "/usr/local/src/php4-STABLE-200304240730/Zend/zend_variables.c", __zend_orig_lineno=44) at /usr/local/src/php4-STABLE-200304240730/Zend/zend_alloc.c:675
#2  0x40402c0e in _mem_block_check (ptr=0x81792bc, silent=1, __zend_filename=0x404e64a0 "/usr/local/src/php4-STABLE-200304240730/Zend/zend_opcode.c", __zend_lineno=159, 
    __zend_orig_filename=0x404e68c0 "/usr/local/src/php4-STABLE-200304240730/Zend/zend_variables.c", __zend_orig_lineno=44) at /usr/local/src/php4-STABLE-200304240730/Zend/zend_alloc.c:667
#3  0x40401d64 in _efree (ptr=0x81792bc, __zend_filename=0x404e64a0 "/usr/local/src/php4-STABLE-200304240730/Zend/zend_opcode.c", __zend_lineno=159, 
    __zend_orig_filename=0x404e68c0 "/usr/local/src/php4-STABLE-200304240730/Zend/zend_variables.c", __zend_orig_lineno=44) at /usr/local/src/php4-STABLE-200304240730/Zend/zend_alloc.c:243
#4  0x40415336 in _zval_dtor (zvalue=0x8178314, __zend_filename=0x404e64a0 "/usr/local/src/php4-STABLE-200304240730/Zend/zend_opcode.c", __zend_lineno=159)
    at /usr/local/src/php4-STABLE-200304240730/Zend/zend_variables.c:44
#5  0x4040e1c6 in destroy_op_array (op_array=0x8179300) at /usr/local/src/php4-STABLE-200304240730/Zend/zend_opcode.c:159
#6  0x4040dfbd in destroy_zend_function (function=0x8179300) at /usr/local/src/php4-STABLE-200304240730/Zend/zend_opcode.c:100
#7  0x4041d1c4 in zend_hash_del_key_or_index (ht=0x8118be8, arKey=0x81792f0 "print_d", nKeyLength=8, h=3787772783, flag=0) at /usr/local/src/php4-STABLE-200304240730/Zend/zend_hash.c:514
#8  0x4041dc07 in zend_hash_reverse_apply (ht=0x8118be8, apply_func=0x4040a8d0 <is_not_internal_function>) at /usr/local/src/php4-STABLE-200304240730/Zend/zend_hash.c:760
#9  0x4040adde in shutdown_executor () at /usr/local/src/php4-STABLE-200304240730/Zend/zend_execute_API.c:201
#10 0x40416ad3 in zend_deactivate () at /usr/local/src/php4-STABLE-200304240730/Zend/zend.c:649
#11 0x403da06c in php_request_shutdown (dummy=0x0) at /usr/local/src/php4-STABLE-200304240730/main/main.c:984
#12 0x4042fae8 in apache_php_module_main (r=0x815c62c, display_source_mode=0) at /usr/local/src/php4-STABLE-200304240730/sapi/apache/sapi_apache.c:61
#13 0x40430b20 in send_php (r=0x815c62c, display_source_mode=0, filename=0x815d0ec "/usr/local/apache/lariat/lariat2/test/test1/index.php")
    at /usr/local/src/php4-STABLE-200304240730/sapi/apache/mod_php4.c:617
#14 0x40430b9f in send_parsed_php (r=0x815c62c) at /usr/local/src/php4-STABLE-200304240730/sapi/apache/mod_php4.c:632

Have you been able to reproduce this on your development machine?

This continues to happen with php4-STABLE-200304281730.  How can I further assist with this bug?

Which version of gcc and binutils are you using?

(appears related to bug #22510 & bug #22367)

bginter@debian:~$ gcc --version
2.95.4

bginter@debian:~$ ld -v
GNU ld version 2.12.90.0.1 20020307 Debian/GNU Linux

I'm looking at crash1.php script.

<?php
$group = new Group;
for ( $i = 0; $i < 15; $i++ ) {
    // uncomment this and it works
    // print $group->count() . "<br/>\n";

    for ( $i = 0; $i < $assoc->count(); $i++ ) {
    // print "Getting company $i<br/>\n";
        $company = $assoc->get( $i );
        $group->add( $company );
    }
    // print_d( $company );
}
print_d( $company );
?>

The above part should be

for ( $j = 0; $j < 15; $j++ ) { // not $i !
    for ( $i = 0; $i < $assoc->count(); $i++ ) {
        $company = $assoc->get( $i );

Otherwise, it goes into an infinite loop when $assoc->count() is less than 15 and then PHP runs out of all the available memory to die.

So that's not a developer issue.

Hrm, so it's not a bug that data are being corrupted and apache is segfaulting?  This isn't bogus.

I opened a seperate bug a week or so ago that is probably related to this one:

<a href="http://bugs.php.net/bug.php?id=23415">#23415</a>

Did you look at the corrupt1.php testcase at all?

Hmm, it's likely crash1.php and corrupt1.php are irrelevant to one another. I just looked at bug #23415, which is very similar to the corrupt1.php case and also seems a valid bug.
So I'm looking into bug #23415 and leaving this one bogus instead.

Please add further comments to bug #23415. Thank you for cooperation.