Bug #68606 [Opn->Asn]: stack overflow/segfault in zend_objects_free_object_storage
| From: | dmitry@php.net | Date: | Thu, 14 Jul 2016 10:57:49 +0000 |
| Subject: | Bug #68606 [Opn->Asn]: stack overflow/segfault in zend_objects_free_object_storage | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-202307@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=68606&edit=1
ID: 68606
Updated by: dmitry@php.net
Reported by: cmshelto at gmail dot com
Summary: stack overflow/segfault in
zend_objects_free_object_storage
-Status: Open
+Status: Assigned
Type: Bug
Package: Reproducible crash
Operating System: Linux
PHP Version: 5.6.3
-Assigned To:
+Assigned To: dmitry
Block user comment: N
Private report: N
Previous Comments:
------------------------------------------------------------------------
[2016-06-15 13:42:44] nikic@php.net
Related To: Bug #72411
------------------------------------------------------------------------
[2014-12-15 18:27:37] requinix@php.net
Related To: Bug #68611
------------------------------------------------------------------------
[2014-12-15 07:18:14] cmshelto at gmail dot com
Description:
------------
The garbage collector segfaults when freeing a deeply nested group of objects. The way this bug
initially appeared, it was not 100000 chained objects but much less; however, they were bigger
objects (more properties).
I have tested this in PHP 5.6.3 and 5.5.13 on Ubuntu 14.04 and PHP 5.5.17 on RHEL7.
The reason I think it is a stack overflow is because when I run it under valgrind with
--main-stacksize=83886080 (10x the default on my machine) then I get the expected output.
As I was trying to create a short enough test case, the offending function seemed to vary but the
functions 'zend_objects_store_del_ref',
'zend_objects_store_del_ref_by_handle_ex', 'zend_object_std_dtor',
'zend_hash_destroy', '_zval_ptr_dtor_wrapper', '_zval_ptr_dtor',
'i_zval_ptr_dtor', and '_zval_dtor' always seemed to be involved.
I can provide a gdb backtrace if necessary; to me, it does not appear any more interesting than the
valgrind output (it is 124544 frames of the functions listed above).
Test script:
---------------
<?php
function fun()
{
$root = NULL;
for ($i = 0; $i < 100000; $i += 1)
{
$tmp = new \stdClass;
$tmp -> aProperty = $root;
$root = $tmp;
}
echo "Finished making objects!\n";
}
fun();
echo "Done!\n";
?>
Expected result:
----------------
Finished making objects!
Done!
Actual result:
--------------
Finished making objects!
Segmentation fault (core dumped)
(Valgrind output):
==6903== Memcheck, a memory error detector
==6903== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==6903== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==6903== Command: ./sapi/cli/php /tmp/gc_bug.php
==6903== Parent PID: 8032
==6903==
==6903== Stack overflow in thread 1: can't grow stack to 0xffe801ff8
==6903==
==6903== Process terminating with default action of signal 11 (SIGSEGV)
==6903== Access not within mapped region at address 0xFFE801FF8
==6903== at 0x9C0101: zval_delref_p (zend.h:410)
==6903== by 0x9C0294: i_zval_ptr_dtor (zend_execute.h:76)
==6903== by 0x9C1564: _zval_ptr_dtor (zend_execute_API.c:427)
==6903== by 0x9D4F1D: _zval_ptr_dtor_wrapper (zend_variables.c:188)
==6903== by 0x9EA5FB: zend_hash_destroy (zend_hash.c:548)
==6903== by 0xA0DBD9: zend_object_std_dtor (zend_objects.c:44)
==6903== by 0xA0E0C8: zend_objects_free_object_storage (zend_objects.c:137)
==6903== by 0xA151C9: zend_objects_store_del_ref_by_handle_ex (zend_objects_API.c:226)
==6903== by 0xA14ECE: zend_objects_store_del_ref (zend_objects_API.c:178)
==6903== by 0x9D4B0C: _zval_dtor_func (zend_variables.c:57)
==6903== by 0x9C023A: _zval_dtor (zend_variables.h:35)
==6903== by 0x9C0301: i_zval_ptr_dtor (zend_execute.h:79)
==6903== by 0x9C1564: _zval_ptr_dtor (zend_execute_API.c:427)
==6903== by 0x9D4F1D: _zval_ptr_dtor_wrapper (zend_variables.c:188)
==6903== by 0x9EA5FB: zend_hash_destroy (zend_hash.c:548)
==6903== by 0xA0DBD9: zend_object_std_dtor (zend_objects.c:44)
==6903== by 0xA0E0C8: zend_objects_free_object_storage (zend_objects.c:137)
==6903== by 0xA151C9: zend_objects_store_del_ref_by_handle_ex (zend_objects_API.c:226)
==6903== by 0xA14ECE: zend_objects_store_del_ref (zend_objects_API.c:178)
==6903== by 0x9D4B0C: _zval_dtor_func (zend_variables.c:57)
==6903== by 0x9C023A: _zval_dtor (zend_variables.h:35)
==6903== by 0x9C0301: i_zval_ptr_dtor (zend_execute.h:79)
==6903== by 0x9C1564: _zval_ptr_dtor (zend_execute_API.c:427)
==6903== by 0x9D4F1D: _zval_ptr_dtor_wrapper (zend_variables.c:188)
==6903== by 0x9EA5FB: zend_hash_destroy (zend_hash.c:548)
==6903== by 0xA0DBD9: zend_object_std_dtor (zend_objects.c:44)
==6903== by 0xA0E0C8: zend_objects_free_object_storage (zend_objects.c:137)
==6903== by 0xA151C9: zend_objects_store_del_ref_by_handle_ex (zend_objects_API.c:226)
==6903== by 0xA14ECE: zend_objects_store_del_ref (zend_objects_API.c:178)
==6903== by 0x9D4B0C: _zval_dtor_func (zend_variables.c:57)
==6903== If you believe this happened as a result of a stack
==6903== overflow in your program's main thread (unlikely but
==6903== possible), you can try to increase the size of the
==6903== main thread stack using the --main-stacksize= flag.
==6903== The main thread stack size used in this run was 8388608.
==6903== Stack overflow in thread 1: can't grow stack to 0xffe801ff8
==6903==
==6903== Process terminating with default action of signal 11 (SIGSEGV)
==6903== Access not within mapped region at address 0xFFE801FF8
==6903== at 0x4A256B0: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-amd64-linux.so)
==6903== If you believe this happened as a result of a stack
==6903== overflow in your program's main thread (unlikely but
==6903== possible), you can try to increase the size of the
==6903== main thread stack using the --main-stacksize= flag.
==6903== The main thread stack size used in this run was 8388608.
==6903==
==6903== HEAP SUMMARY:
==6903== in use at exit: 39,189,162 bytes in 520,804 blocks
==6903== total heap usage: 524,822 allocs, 4,018 frees, 47,723,472 bytes allocated
==6903==
==6903== LEAK SUMMARY:
==6903== definitely lost: 0 bytes in 0 blocks
==6903== indirectly lost: 0 bytes in 0 blocks
==6903== possibly lost: 0 bytes in 0 blocks
==6903== still reachable: 39,189,162 bytes in 520,804 blocks
==6903== suppressed: 0 bytes in 0 blocks
==6903== Rerun with --leak-check=full to see details of leaked memory
==6903==
==6903== For counts of detected and suppressed errors, rerun with: -v
==6903== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=68606&edit=1