Bug #72144 [Opn->Fbk]: _emalloc_24 crash on recursive call

Edit report at https://bugs.php.net/bug.php?id=72144&edit=1 ID: 72144 Updated by: nikic@php.net Reported by: php at abiusx dot com Summary: _emalloc_24 crash on recursive call -Status: Open +Status: Feedback Type: Bug Package: *Programming Data Structures Operating System: Mac OS X 10.11 PHP Version: 7.0.6 Block user comment: N Private report: N New Comment: The problem from the original report seems to be resolved. Is the crash mentioned later in the comments still reproducible? Previous Comments: ------------------------------------------------------------------------ [2016-05-31 20:46:15] php at abiusx dot com confirmed that the crash occurs when cloning and object in its own constructor, and then deleting the clone, causing the destructor to be called. Static variables are also involved in all of this. Was unable to isolate to a simple piece of code that reproduces this. ------------------------------------------------------------------------ [2016-05-31 17:55:59] php at abiusx dot com With PHP 7.0.7, it appears that most of the problem is solved. The only crashing thing is now a fairly complex piece of code that is executed in an object destructor, which results in the following: ------ 36.16 Running wpdb::__destruct()... --------- 36.16.1 Found direct method wpdb::__destruct()... --------- 36.16.2 wp-includes/wp-db.php:658 phpd(66402,0x7fff75d48000) malloc: *** error for object 0x7ffafc9a3770: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Abort trap: 6 I couldn't get any useful errors out of it even with debug version. This is run with USE_ZEND_ALLOC=0, and otherwise it would crash at the same exact point. Both destructors that cause this also return true. I am under the impression that the interpreter state is somehow corrupt inside the destructor. ------------------------------------------------------------------------ [2016-05-24 18:44:05] php at abiusx dot com Nop, tried with 8MB, 10MB and 50MB stack sizes. All crash at the same instruction. Interestingly, using ZendMM, the program crashes a few hundred instructions later than where it crashes under USE_ZEND_ALLOC=0. The former crashes in a recursive function, whereas the latter crashes on the emulator. This is all with regards to extending the PHP-Emulator (https://github.com/abiusx/php-emul) to support PHP static/dynamic code analysis. The heavy part seems to be the deep_copy operation needed for concolic execution. ------------------------------------------------------------------------ [2016-05-24 18:40:49] php at abiusx dot com Most of them are related to libxml. It is not from PHP, but from the dylibs used by PHP under OS X. At least 18 false positive memory leaks are reported all the time, although no access violation. Tried with ulimit -s before, didn't effect were it crashes. I am still working on that and will report in a few minutes. The debug-enabled PHP version I currently have built lacks many libraries needed for this code. It seems likely to be a stack issue, specially since OS X has a 64MB limit on stack, however, I can't see where such stack usage comes into play. The stack depth is less than 10 in this code, although a recursive function is in play. Will report in a few minutes about stack modifications. ------------------------------------------------------------------------ [2016-05-24 18:37:23] nikic@php.net You can control the stack size limit using "ulimit -s". What false positives does valgrind give you? PHP is usually clean under valgrind. Or are you using something like openssl in your code (or indirectly by making HTTPS requests)? ------------------------------------------------------------------------ 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=72144 -- Edit this bug report at https://bugs.php.net/bug.php?id=72144&edit=1