Bug #74804 [Opn]: Segfault when instantiating object in array

Edit report at https://bugs.php.net/bug.php?id=74804&edit=1 ID: 74804 User updated by: steve dot hall+bugs dot php dot net at rg456 dot co dot uk Reported by: steve dot hall+bugs dot php dot net at rg456 dot co dot uk Summary: Segfault when instantiating object in array Status: Open Type: Bug Package: Reproducible crash Operating System: Alpine 3.4 & Windows 10 PHP Version: 7.1.6 Block user comment: N Private report: N New Comment: New valgrind here with "export USE_ZEND_ALLOC=0" and ZEND_DONT_UNLOAD_MODULES=1 and a couple of Invalid reads/writes: https://gist.github.com/sh41/2dd25967ec598f4f48bbdf049df2e462#file-valgrind-L7126 I will try to eliminate un-needed extensions with -n and provide another one as soon as I can. Previous Comments: ------------------------------------------------------------------------ [2017-06-23 11:20:43] nikic@php.net It's okay if you don't get a segfault, the important part is whether you get invalid reads/writes in valgrind. I would suggest to: * Try running under php -n and only enable those extensions that are necessary to reproduce this. In particular running with openssl adds a lot of noise to valgrind output, because openssl developers have some very peculiar views on reading uninitialized data from memory. * Try setting ZEND_DONT_UNLOAD_MODULES=1 to avoid some of the ???s in the output. * Try running with USE_ZEND_ALLOC=0 again and see if there are still invalid read/writes, even if there is no segfault. (Disregard the ones caused by "invalid file descriptor", those don't seem related.) ------------------------------------------------------------------------ [2017-06-23 10:49:21] steve dot hall+bugs dot php dot net at rg456 dot co dot uk With export USE_ZEND_ALLOC=0 I cannot cause the segfault in valgrind, but as soon as I do export USE_ZEND_ALLOC=1 The segfault reappears. New file here: https://gist.github.com/sh41/df3d2b8e3695d67ef59653b83e5604d0 ------------------------------------------------------------------------ [2017-06-23 10:39:52] steve dot hall+bugs dot php dot net at rg456 dot co dot uk Apologies, I spoke to soon. The segfault is happening again. I am attempting to capture a new valgrind without the igbinary extension, but the segfault goes away when I'm running in valgrind. ------------------------------------------------------------------------ [2017-06-23 10:10:45] steve dot hall+bugs dot php dot net at rg456 dot co dot uk I may have stumbled over the problem. We had the https://github.com/igbinary/igbinary extension enabled, but weren't deliberately using anywhere. I have now removed it from the configuration and cannot cause the seg fault anymore. ------------------------------------------------------------------------ [2017-06-23 09:43:52] nikic@php.net The relevant part of the valgrind log seems to be: ==787== Invalid read of size 8 ==787== at 0x5B2952: gc_remove_from_buffer (in /usr/local/bin/php) ==787== by 0x5C78BC: zend_objects_store_del (in /usr/local/bin/php) ==787== by 0x62A9F9: ??? (in /usr/local/bin/php) ==787== by 0x5D267A: execute_ex (in /usr/local/bin/php) ==787== by 0x579FB4: zend_call_function (in /usr/local/bin/php) ==787== by 0x5A7398: zend_call_method (in /usr/local/bin/php) ==787== by 0x5C2881: zend_objects_destroy_object (in /usr/local/bin/php) ==787== by 0x5B305D: zend_gc_collect_cycles (in /usr/local/bin/php) ==787== by 0x5B2900: gc_possible_root (in /usr/local/bin/php) ==787== by 0x4ED42F: var_destroy (in /usr/local/bin/php) ==787== by 0x4ED4B1: php_var_unserialize_destroy (in /usr/local/bin/php) ==787== by 0x4DC2E1: ??? (in /usr/local/bin/php) ==787== by 0x629F41: ??? (in /usr/local/bin/php) ==787== by 0x5D267A: execute_ex (in /usr/local/bin/php) ==787== by 0x579FB4: zend_call_function (in /usr/local/bin/php) ==787== by 0x499A8A: ??? (in /usr/local/bin/php) ==787== by 0x629F41: ??? (in /usr/local/bin/php) ==787== by 0x5D267A: execute_ex (in /usr/local/bin/php) ==787== by 0x579FB4: zend_call_function (in /usr/local/bin/php) ==787== by 0x445213: ??? (in /usr/local/bin/php) ==787== by 0x62AE5F: ??? (in /usr/local/bin/php) ==787== by 0x5D267A: execute_ex (in /usr/local/bin/php) ==787== by 0x62CDDF: zend_execute (in /usr/local/bin/php) ==787== by 0x5890B2: zend_execute_scripts (in /usr/local/bin/php) ==787== by 0x525FAF: php_execute_script (in /usr/local/bin/php) ==787== by 0x62F03D: ??? (in /usr/local/bin/php) ==787== by 0x21AAD0: ??? (in /usr/local/bin/php) ==787== by 0x401D836: (below main) (in /lib/ld-musl-x86_64.so.1) ==787== Address 0x4f1c4b0 is 16 bytes after a block of size 320,032 alloc'd ==787== at 0x4C91A2C: malloc (vg_replace_malloc.c:299) ==787== by 0x5B2846: gc_init (in /usr/local/bin/php) ==787== by 0x5880E9: ??? (in /usr/local/bin/php) ==787== by 0x5A474B: zend_register_ini_entries (in /usr/local/bin/php) ==787== by 0x525534: php_module_startup (in /usr/local/bin/php) ==787== by 0x62DE9C: ??? (in /usr/local/bin/php) ==787== by 0x21A9C2: ??? (in /usr/local/bin/php) ==787== by 0x401D836: (below main) (in /lib/ld-musl-x86_64.so.1) Looks like we're reading past the end of the GC buffer, but I don't see how that can happen inside that function, as all accesses to the GC buffer are bounds-checked. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=74804 -- Edit this bug report at https://bugs.php.net/bug.php?id=74804&edit=1