|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2015-12-11 14:05 UTC] emilie dot guth at gmail dot com
Description:
------------
I get a segfault with this code while including an empty file (see test script which contains a.php and c.php).
This bug comes from a larger script, so I tried to get the shortest test script I could. When I change a tiny little thing (switch to if, no id() function ...) in it, there is no more segfault.
I'm working on Mac OS X Version 10.11.1 with PHP 7.0.0 :
$ php -v
PHP 7.0.0 (cli) (built: Dec 11 2015 14:48:07) ( NTS )
I tried the same code on an Ubuntu 15.10 computer with PHP 7.0.0 there is no problem at all.
Test script:
---------------
File a.php :
<?php
declare(strict_types = 1);
function id() {
return ['id'];
}
function boom(): array {
$data = [id()];
switch($data[0]) {
case ['id'] : return;
}
}
set_exception_handler(function($e) {
require_once './c.php';
echo "plop";
});
boom();
?>
File c.php :
<?php
?>
Expected result:
----------------
I am supposed to be shown "plop" as a result.
Instead of that I get :
$ php a.php
Segmentation fault: 11
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Mon Nov 03 18:00:01 2025 UTC |
Reduced script: <?php function boom(): array { $data = [['id']]; switch($data[0]) { case ['id']: return; } } boom(); Valgrind: ==12769== Invalid read of size 4 ==12769== at 0xB2BCC2: zval_delref_p (zend_types.h:827) ==12769== by 0xB2C278: i_zval_ptr_dtor (zend_variables.h:57) ==12769== by 0xB305AA: zend_array_destroy (zend_hash.c:1301) ==12769== by 0xB14474: _zval_dtor_func_for_ptr (zend_variables.c:96) ==12769== by 0xB0376C: _zval_ptr_dtor_nogc (zend_variables.h:50) ==12769== by 0xB04953: destroy_op_array (zend_opcode.c:377) ==12769== by 0xB03B5D: zend_function_dtor (zend_opcode.c:124) ==12769== by 0xB2F98C: _zend_hash_del_el_ex (zend_hash.c:992) ==12769== by 0xB2FA57: _zend_hash_del_el (zend_hash.c:1016) ==12769== by 0xB312F3: zend_hash_reverse_apply (zend_hash.c:1594) ==12769== by 0xAFD15C: shutdown_executor (zend_execute_API.c:366) ==12769== by 0xB17E19: zend_deactivate (zend.c:967) ==12769== Address 0xf4591f0 is 0 bytes inside a block of size 56 free'd ==12769== at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==12769== by 0xADB2C2: _efree (zend_alloc.c:2453) ==12769== by 0xB3071D: zend_array_destroy (zend_hash.c:1327) ==12769== by 0xB14474: _zval_dtor_func_for_ptr (zend_variables.c:96) ==12769== by 0xB2C295: i_zval_ptr_dtor (zend_variables.h:58) ==12769== by 0xB305AA: zend_array_destroy (zend_hash.c:1301) ==12769== by 0xB14474: _zval_dtor_func_for_ptr (zend_variables.c:96) ==12769== by 0xB7C620: i_free_compiled_variables (zend_execute.c:2061) ==12769== by 0xB7E1EA: zend_leave_helper_SPEC (zend_vm_execute.h:470) ==12769== by 0xB82404: ZEND_HANDLE_EXCEPTION_SPEC_HANDLER (zend_vm_execute.h:1550) ==12769== by 0xB7DF9F: execute_ex (zend_vm_execute.h:414) ==12769== by 0xB7E1A1: zend_execute (zend_vm_execute.h:458) We free the switch var before return and then exception loop var cleanup likely tries to free it a second time.hmm, I see nothing , $ USE_ZEND_ALLOC=0 valgrind sapi/cli/php /tmp/1.php ==17985== Memcheck, a memory error detector ==17985== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==17985== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info ==17985== Command: sapi/cli/php /tmp/1.php ==17985== PHP Fatal error: Uncaught TypeError: Return value of boom() must be of the type array, none returned in /tmp/1.php:7 Stack trace: #0 /tmp/1.php(11): boom() #1 {main} thrown in /tmp/1.php on line 7 Fatal error: Uncaught TypeError: Return value of boom() must be of the type array, none returned in /tmp/1.php:7 Stack trace: #0 /tmp/1.php(11): boom() #1 {main} thrown in /tmp/1.php on line 7 ==17985== ==17985== HEAP SUMMARY: ==17985== in use at exit: 85,994 bytes in 2,661 blocks ==17985== total heap usage: 23,070 allocs, 20,409 frees, 3,272,823 bytes allocated ==17985== ==17985== LEAK SUMMARY: ==17985== definitely lost: 360 bytes in 2 blocks ==17985== indirectly lost: 272 bytes in 3 blocks ==17985== possibly lost: 0 bytes in 0 blocks anyway thing I missed?