Description:
------------
We are actually running on php4-STABLE-200307160330.
uname -a:

[root@shibboleth http-debug]# uname -a
Linux shibboleth.unspunrecords.com 2.4.2-ac20 #3 Wed 
Mar 21 07:23:43 PST 2001 i686 unknown

zend_hash_find causes a segmentation fault at random 
intervals in a running site, after long uptimes (and 
sometimes immediately on startup)

It appears that the hashtable (ht) holds a corrupt 
pointer and this is what is causing the crash. I have a 
core dump and binary available to anyone who wants to 
look at it.

In every frame of the backtrace, I can't view hashtable 
(and I assume I should be able to, right?)

Also, I realize that I am filing a bug on dev code -- 
We have had a similar issue (random core dumps after 
long uptimes) in nearly every version of PHP up to now, 
and this is the first time I was able to capture a core 
dump because we run our server in a chroot which was 
making it quite hard to capture this error properly.

Reproduce code:
---------------
I believe this is caused during an auto-increment operation as part of a hashtable lookup:

in top.php (called from index.php):

<?
  $browse_type = $HTTP_GET_VARS["browse_type"];
?>

Considering that this lookup is the first lookup done by any code on this request, it seems almost certain that the hashtable is being clobbered.

Expected result:
----------------
$browse_type should be set with the contents of 
$HTTP_GET_VARS["browse_type"]

Actual result:
--------------
(gdb) frame 0
(gdb) print ht     
$25 = (HashTable *) 0x6574693f
(gdb) print *ht
Cannot access memory at address 0x6574693f

and...

(gdb) backtrace
#0  0x809aed9 in zend_hash_find (ht=0x825660c, 
arKey=0x8287a6c "browse_type", 
    nKeyLength=12, pData=0xbfffba1c)
    at /unspun/src/php4-STABLE-200307160330/Zend/
zend_hash.c:880
#1  0x809fcc8 in zend_fetch_dimension_address 
(result=0x829a5bc, 
    op1=0x829a5cc, op2=0x829a5dc, Ts=0xbfffbb18, 
type=0)
    at /unspun/src/php4-STABLE-200307160330/Zend/
zend_execute.c:633
#2  0x80a342e in execute (op_array=0x8284424)
    at /unspun/src/php4-STABLE-200307160330/Zend/
zend_execute.c:1283
#3  0x80ab680 in execute (op_array=0x8254274)
    at /unspun/src/php4-STABLE-200307160330/Zend/
zend_execute.c:2177
#4  0x8096ffe in zend_execute_scripts (type=8, 
retval=0x0, file_count=3)
    at /unspun/src/php4-STABLE-200307160330/Zend/
zend.c:886
#5  0x8079ff6 in php_execute_script 
(primary_file=0xbffff5d8)
    at /unspun/src/php4-STABLE-200307160330/main/
main.c:1685
#6  0x80ad6b6 in apache_php_module_main (r=0x824dbbc, 
display_source_mode=0)
    at /unspun/src/php4-STABLE-200307160330/sapi/
apache/sapi_apache.c:54
#7  0x807359c in send_php ()
#8  0x80735f9 in send_parsed_php ()
#9  0x813600b in ap_invoke_handler ()
#10 0x814b0ab in process_request_internal ()
#11 0x814b4e3 in ap_internal_redirect ()
#12 0x806c548 in handle_dir ()
#13 0x813600b in ap_invoke_handler ()
---Type <return> to continue, or q <return> to quit--- 
#14 0x814b0ab in process_request_internal ()
#15 0x814b10c in ap_process_request ()
#16 0x8142021 in child_main ()
#17 0x81422b3 in make_child ()
#18 0x8142364 in startup_children ()
#19 0x81429dc in standalone_main ()
#20 0x814325b in main ()
#21 0x400c0b5c in __libc_start_main (main=0x8142e98 
<main>, argc=1, 
    ubp_av=0xbffffaec, init=0x8066840 <_init>, 
fini=0x81735bc <_fini>, 
    rtld_fini=0x4000d634 <_dl_fini>, 
stack_end=0xbffffae4)
    at ../sysdeps/generic/libc-start.c:129