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

From: Date: Mon, 03 Jul 2017 15:44:27 +0000
Subject: Bug #74804 [Opn]: Segfault when instantiating object in array
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-209789@lists.php.net to get a copy of this message
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: Based on what we know so far, this is likely an instance of bug #72530. Previous Comments: ------------------------------------------------------------------------ [2017-06-23 14:41:33] steve dot hall+bugs dot php dot net at rg456 dot co dot uk Thank you for your time on this nikic, it is much appreciated. Here is a valgrind from php -n https://gist.github.com/sh41/30890b1021cac6bec0530292ffc5fd11 I've included the output of php -n -i so that you can see what extensions are loaded. I think that openssl is compiled in, and it's also required by the program I'm running, so don't think I can usefully revert to a version without it. Must admit that I'm out of my depth when it comes to php internals, but if it helps, the times I was able to catch the seg fault in action it seemed to happen at this line: https://github.com/symfony/symfony/blob/v3.3.2/src/Symfony/Component/VarDumper/Cloner/VarCloner.php#L123 Not sure if that helps to point in the right direction or not. Is there anything else I can do to provide more information on this? ------------------------------------------------------------------------ [2017-06-23 14:31:43] nikic@php.net The last valgrind output looks pretty good. This seems to be some kind of GC issue involving destructors and nested GCs. From the valgrind output, what seems to be happening: 1. During the outer GC, while running a destructor and object is created. 2. During the inner GC that object is freed. 3. During the outer GC, there is an attempt to free the object again. Not sure how we could actually end up in that situation though. It might help to find out which __destruct() method is involved here. (From the trace, the __destruct() might be calling __invoke() on a closure, though it's not clear if that's a direct call.) ------------------------------------------------------------------------ [2017-06-23 13:55:50] steve dot hall+bugs dot php dot net at rg456 dot co dot uk 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. ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ 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

« previous php.bugs (#209789) next »