Bug #73545 [Opn->Ver]: Valgrind error/crash with static property access

From: 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

« previous php.bugs (#205416) next »