ID: 24695
Updated by: [EMAIL PROTECTED]
Reported By: jna at retina dot net
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Redhat Linux 7.2
PHP Version: 5CVS-2003-07-17 (dev)
New Comment:
> We are actually running on php4-STABLE-200307160330.
Then why the hell did you put "5CVS..." in Version ??!
Previous Comments:
------------------------------------------------------------------------
[2003-07-17 15:59:39] jna at retina dot net
Description:
------------
We are actually running on php4-STABLE-200307160330.
uname -a:
[EMAIL PROTECTED] 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
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=24695&edit=1
