Bug #73545 [Opn->Ver]: Valgrind error/crash with static property access
| From: | cmb@php.net | Date: | Wed, 16 Nov 2016 19:24:37 +0000 |
| Subject: | Bug #73545 [Opn->Ver]: Valgrind error/crash with static property access | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-205416@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=73545&edit=1
ID: 73545
Updated by: cmb@php.net
Reported by: derick@php.net
Summary: Valgrind error/crash with static property access
-Status: Open
+Status: Verified
Type: Bug
Package: Reproducible crash
Operating System: Linux (Debian Jessie 8)
PHP Version: 5.6.28
Block user comment: N
Private report: N
New Comment:
I can reproduce this issue, and interestingly, for me a second
valgrind issue is reported:
vagrant@debian-8:/vagrant/php-src$ USE_ZEND_ALLOC=0 valgrind --track-origins=ye
s sapi/cli/php -n ../73545.php
==4854== Memcheck, a memory error detector
==4854== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==4854== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==4854== Command: sapi/cli/php -n ../73545.php
==4854==
==4854== Conditional jump or move depends on uninitialised value(s)
==4854== at 0x5A4087: zend_lookup_class_ex (zend_execute_API.c:944)
==4854== by 0x5A4DEC: zend_fetch_class_by_name (zend_execute_API.c:1418)
==4854== by 0x601835: ZEND_INIT_STATIC_METHOD_CALL_SPEC_CONST_CONST_HANDLER
(zend_vm_execute.h:3833)
==4854== by 0x5ED80A: execute_ex (zend_vm_execute.h:363)
==4854== by 0x5B4E77: zend_execute_scripts (zend.c:1341)
==4854== by 0x545359: php_execute_script (main.c:2613)
==4854== by 0x66A201: do_cli (php_cli.c:998)
==4854== by 0x419822: main (php_cli.c:1382)
==4854== Uninitialised value was created by a stack allocation
==4854== at 0x5A3FD6: zend_lookup_class_ex (zend_execute_API.c:907)
==4854==
==4854== Conditional jump or move depends on uninitialised value(s)
==4854== at 0x5E0B99: zend_std_get_static_method (zend_object_handlers.c:1261)
==4854== by 0x601899: ZEND_INIT_STATIC_METHOD_CALL_SPEC_CONST_CONST_HANDLER
(zend_vm_execute.h:3887)
==4854== by 0x5ED80A: execute_ex (zend_vm_execute.h:363)
==4854== by 0x5B4E77: zend_execute_scripts (zend.c:1341)
==4854== by 0x545359: php_execute_script (main.c:2613)
==4854== by 0x66A201: do_cli (php_cli.c:998)
==4854== by 0x419822: main (php_cli.c:1382)
==4854== Uninitialised value was created by a stack allocation
==4854== at 0x5E0B20: zend_std_get_static_method (zend_object_handlers.c:1180)
==4854==
==4854==
==4854== HEAP SUMMARY:
==4854== in use at exit: 0 bytes in 0 blocks
==4854== total heap usage: 11,938 allocs, 11,938 frees, 1,858,772 bytes allocated
==4854==
==4854== All heap blocks were freed -- no leaks are possible
==4854==
==4854== For counts of detected and suppressed errors, rerun with: -v
==4854== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
After inserting a printf() for debug purposes in
zend_object_handlers.c:1261 the second valgrind issue is gone.
[1] $ gcc --version
gcc (Debian 4.9.2-10) 4.9.2
Previous Comments:
------------------------------------------------------------------------
[2016-11-16 18:36:47] derick@php.net
Description:
------------
Through https://bugs.xdebug.org/view.php?id=1337 I ran
into a bug in PHP
proper.
This bug seems to be triggered only with PHP 5.5/5.6, and so far, I have only been able to reproduce
this on Debian Jessie 8 with a stock gcc compiler, and *not* in debug more (i.e., -O2 is used).
Running the test script with "export USE_ZEND_ALLOC=0" and with "valgrind php -n
index.php" reproduces the issue.
From internals:
> zend_std_get_static_method() declares use_heap[1] (if there's support
> for alloca), but doesn't initialize it with SET_ALLOCA_FLAG()[2]. It
> seems to me that ALLOCA_FLAG() should be defined like so:
>
> # define ALLOCA_FLAG(name) \
> zend_bool name = 0;
Nikita wrote:
> This shouldn't be a problem. alloca is only used in the !key branches, in
> which case the flag is initialized by do_alloca.
I wrote:
> However, it is a problem as my valgrind note says. However, I wouldn't
> be surprised if this was a (Debian) GCC bug. I can't reproduce this when
> I change -O2 to -O0 in the Makefile.
>
> In the past, I have found a similar issue in Xdebug, where it was really
> something Xdebug was doing wrong, but in a very vague way
> (https://github.com/xdebug/xdebug/commit/c36ea38141cb9403ff4bf72602fcf4ae62e5ba1e).
>
> However, right now, it's a bug with this GCC version.
>
Dmitry wrote:
This is possible.
In this backtracked "key" has to be not NULL, and the line 1261 shouldn't be reached
at all.
-----
But it is still a bug, and IMO something that PHP needs to address as it affects everybody running
PHP on Debian 8.
Test script:
---------------
<?php
class A {
static private $a;
static public function init() {
self::$a = 123;
}
}
A::init();
Expected result:
----------------
It outputs the following:
root@debian-8-64bit:/home/derick/xdebug-issue-1185# valgrind php -n index.php
==760== Memcheck, a memory error detector
==760== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==760== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==760== Command: php -n index.php
==760==
==760== Conditional jump or move depends on uninitialised value(s)
==760== at 0x797992: zend_std_get_static_method (zend_object_handlers.c:1261)
==760== by 0x7B66FE: ZEND_INIT_STATIC_METHOD_CALL_SPEC_CONST_CONST_HANDLER
(zend_vm_execute.h:3887)
==760== by 0x7A379F: execute_ex (zend_vm_execute.h:363)
==760== by 0x76E2AF: zend_execute_scripts (zend.c:1341)
==760== by 0x70CC87: php_execute_script (main.c:2613)
==760== by 0x81A990: do_cli (php_cli.c:998)
==760== by 0x431996: main (php_cli.c:1382)
==760==
succcess!==760==
==760== HEAP SUMMARY:
==760== in use at exit: 96 bytes in 3 blocks
==760== total heap usage: 19,605 allocs, 19,602 frees, 3,589,979 bytes allocated
==760==
==760== LEAK SUMMARY:
==760== definitely lost: 0 bytes in 0 blocks
==760== indirectly lost: 0 bytes in 0 blocks
==760== possibly lost: 0 bytes in 0 blocks
==760== still reachable: 96 bytes in 3 blocks
==760== suppressed: 0 bytes in 0 blocks
==760== Rerun with --leak-check=full to see details of leaked memory
==760==
==760== For counts of detected and suppressed errors, rerun with: -v
==760== Use --track-origins=yes to see where uninitialised values come from
==760== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Actual result:
--------------
No valgrind warning.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=73545&edit=1