php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #24695 SEGV in zend_hash_find - possible memory corruption?
Submitted: 2003-07-17 15:59 UTC Modified: 2003-07-24 15:12 UTC
Votes:1
Avg. Score:1.0 ± 0.0
Reproduced:0 of 1 (0.0%)
From: jna at retina dot net Assigned:
Status: No Feedback Package: Scripting Engine problem
PHP Version: 5CVS-2003-07-17 (dev) OS: Redhat Linux 7.2
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: jna at retina dot net
New email:
PHP Version: OS:

 

 [2003-07-17 15:59 UTC] jna at retina dot net
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

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-07-17 21:21 UTC] sniper@php.net
> We are actually running on php4-STABLE-200307160330.

Then why the hell did you put "5CVS..." in Version ??!

 [2003-07-17 21:23 UTC] sniper@php.net
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.



 [2003-07-24 15:12 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Sun Feb 05 02:05:48 2023 UTC