php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #73545 Valgrind error/crash with static property access
Submitted: 2016-11-16 18:36 UTC Modified: 2016-12-01 15:31 UTC
Votes:2
Avg. Score:4.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:2 (100.0%)
From: derick@php.net Assigned: dmitry (profile)
Status: Closed Package: Reproducible crash
PHP Version: 5.6.28 OS: Linux (Debian Jessie 8)
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: derick@php.net
New email:
PHP Version: OS:

 

 [2016-11-16 18:36 UTC] 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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-11-16 19:24 UTC] cmb@php.net
-Status: Open +Status: Verified
 [2016-11-16 19:24 UTC] cmb@php.net
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
 [2016-12-01 15:31 UTC] dmitry@php.net
-Status: Verified +Status: Closed -Assigned To: +Assigned To: dmitry
 [2016-12-01 15:31 UTC] dmitry@php.net
The fix for this bug has been committed.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Nov 24 07:02:12 2024 UTC