Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55693
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain tekelec.com from 198.89.35.103 cause and error)
To: "internals@lists.php.net" <internals@lists.php.net>
Date: Mon, 3 Oct 2011 15:42:28 -0400
Thread-Topic: zend memory managment null pointer dereference
Thread-Index: AcyCBJUpPyx8RAAQQ4unKMiLkp3YOA==
Message-ID: <F4F95B37FBE5E644988011E91104C762033A3C6BC0@MAIL1.tekelec.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative;
	boundary="_000_F4F95B37FBE5E644988011E91104C762033A3C6BC0MAIL1tekelecc_"
MIME-Version: 1.0
Subject: zend memory managment null pointer dereference
From: Alan.Chester@tekelec.com ("Chester, Alan")

--_000_F4F95B37FBE5E644988011E91104C762033A3C6BC0MAIL1tekelecc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I have recently seen httpd core dump on my system.  After looking into this=
 issue it is the php module which is actually core dumping more specificall=
y the zend memory management part of php.

#0  0x0115d224 in zend_mm_remove_from_free_list (heap=3D0x99596e8,
    p=3D<value optimized out>)
    at /scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_all=
oc.c:837

The following line is failing in zend_mm_remove_from_fee_list which is in z=
end_alloc.c

#if ZEND_MM_SAFE_UNLINKING
        if (UNEXPECTED(prev->next_free_block !=3D mm_block) || UNEXPECTED(n=
ext->prev_free_block !=3D mm_block)) {
            zend_mm_panic("zend_mm_heap corrupted");
        }
#endif

The core file tells me that next pointer is null so this is crashing when t=
rying to dereference a null pointer.  My first question is next ever expect=
ed to be null?  After looking through the code, it seems that if there is o=
nly one element in the list that next & prev will be both equal to mm_block=
, is this a true assumption?

I am not sure what has gotten my system into this state the only hints I ha=
ve is that there were a fair amount of objects created and an init 6 was se=
nt and during the shut down of the php module this issue was seen.

I have done some investigation into this issue and came across a fairly lon=
g bug report https://bugs.php.net/bug.php?id=3D40479.  However I am not sur=
e if this is the same issue since I never see the "zend_mm_heap corrupted" =
message since the code fails due to the null pointer dereference before out=
putting this error message however this may be related in the fact that my =
heap is being corrupted.

Since I do not have a solid reproducer or know why my heap is in this state=
.  I was wondering if I could get some information to help me debug this.  =
Do you have any hunches on what could be setting next to null?  What does i=
t mean when next is null is this because the list is at the end or is this =
a dangling pointer and next should never be null?  Do you have any hints on=
 a possible reproducer using just php which would put me into the state whe=
re next is null?  Also during my research on similar issues I have read tha=
t cache may have a role in causing the heap to be corrupted.  How could the=
 cache be corrupting the heap? Is that possible?

My current version of php is:
PHP 5.2.17 (cli) (built: Aug  2 2011 13:33:29)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
    with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans

I am running centos 5.6 and this issue has been seen on both 32 bit and 64 =
bit.


Also this issue has been seen only after upgrading from php 5.2.6 to 5.2.17=
.  Do you know of a change made between these releases that could have an a=
ffect on the memory management?

Thread 1 (Thread 30656):
#0  0x0115d224 in zend_mm_remove_from_free_list (heap=3D0x99596e8,
    p=3D<value optimized out>)
    at /scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_all=
oc.c:837
#1  _zend_mm_free_int (heap=3D0x99596e8, p=3D<value optimized out>)
    at /scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_all=
oc.c:1979
#2  0x0117965a in _zval_dtor_func (zvalue=3D0x9a2e300)
    at /scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_var=
iables.c:43
#3  0x0116c388 in _zval_dtor (zval_ptr=3D0x9d60ae0)
    at /scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_var=
iables.h:35
#4  _zval_ptr_dtor (zval_ptr=3D0x9d60ae0)
    at /scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_exe=
cute_API.c:414
#5  0x01184d77 in zend_hash_destroy (ht=3D0x9d5ecfc)
    at /scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_has=
h.c:526
#6  0x0117050d in destroy_zend_class (pce=3D0x9eaf7b4)
    at /scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_opc=
ode.c:185
#7  0x01184d77 in zend_hash_destroy (ht=3D0x99599b0)
    at /scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_has=
h.c:526
#8  0x0117a09e in zend_shutdown ()
    at /scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend.c:7=
36
#9  0x01131f35 in php_module_shutdown ()
    at /scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/main/main.c:1=
918
#10 0x01131ff7 in php_module_shutdown_wrapper (sapi_globals=3D0x12849e0)
    at /scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/main/main.c:1=
889
#11 0x01202211 in php_apache_child_shutdown (tmp=3D0x0)
    at /scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/sapi/apache2h=
andler/sapi_apache2.c:369
#12 0x00cdbe8d in ?? () from /usr/lib/libapr-1.so.0
#13 0x00cdc63d in apr_pool_destroy () from /usr/lib/libapr-1.so.0
#14 0x003909e5 in ?? ()
#15 0x00390a0d in ?? ()
#16 <signal handler called>
#17 zend_hash_destroy (ht=3D0xa42b9a8)
    at /scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_has=
h.c:522

Thanks,
Alan


--_000_F4F95B37FBE5E644988011E91104C762033A3C6BC0MAIL1tekelecc_--