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

Edit report at https://bugs.php.net/bug.php?id=74804&edit=1 ID: 74804 Updated by: nikic@php.net 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: 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.) Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2017-06-23 09:25:19] steve dot hall+bugs dot php dot net at rg456 dot co dot uk Description: ------------ I get a segmentation fault on this line: https://github.com/symfony/symfony/blob/v3.3.2/src/Symfony/Component/VarDumper/Cloner/VarCloner.php#L123 The line runs perfectly well a few thousand times, but then seg faults at a certain point. I have been unable to recreate the bug in anything less than the total application that I am working on, and at this time I'm unable to share the full source code. I have tried capturing the state of all the variables involved using xDebug and reproducing in a standalone script but that doesn't cause the seg fault. I've serialized the variables and then attempted to read them back in and run the code in question but that doesn't cause it either. I've tried on Windows 10 with PHP 7.1.6 and Alpine Linux 3.4 with PHP 7.1.6 (in a container) and get the same seg fault on both. Test script: --------------- Have been unable to demonstrate in anything less than the full application. Expected result: ---------------- No segmentation fault. Actual result: -------------- GDB output and valgrind are here: https://gist.github.com/sh41/c1b5b6d0f2539357303fa43961fe2c95 ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=74804&edit=1