Bug #73545 [NEW]: Valgrind error/crash with static property access
| From: | derick@php.net | Date: | Wed, 16 Nov 2016 18:36:50 +0000 |
| Subject: | Bug #73545 [NEW]: Valgrind error/crash with static property access | ||
| Groups: | php.bugs | ||
| Request: | Send a blank email to php-bugs+get-205414@lists.php.net to get a copy of this message | ||
From: derick@php.net
Operating system: Linux (Debian Jessie 8)
PHP version: 5.6.28
Package: Reproducible crash
Bug Type: Bug
Bug description:Valgrind error/crash with static property access
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 bug report at https://bugs.php.net/bug.php?id=73545&edit=1
--
Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=73545&r=trysnapshot54
Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=73545&r=trysnapshot55
Try a snapshot (trunk): https://bugs.php.net/fix.php?id=73545&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=73545&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=73545&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=73545&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=73545&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=73545&r=oldversion
Not developer issue: https://bugs.php.net/fix.php?id=73545&r=support
Expected behavior: https://bugs.php.net/fix.php?id=73545&r=notwrong
Not enough info: https://bugs.php.net/fix.php?id=73545&r=notenoughinfo
Submitted twice: https://bugs.php.net/fix.php?id=73545&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=73545&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=73545&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=73545&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=73545&r=isapi
Install GNU Sed: https://bugs.php.net/fix.php?id=73545&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=73545&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=73545&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=73545&r=mysqlcfg