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

Edit report at https://bugs.php.net/bug.php?id=72144&edit=1 ID: 72144 User updated by: php at abiusx dot com Reported by: php at abiusx dot com Summary: _emalloc_24 crash on recursive call Status: Open 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: 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. Previous Comments: ------------------------------------------------------------------------ [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)? ------------------------------------------------------------------------ [2016-05-24 18:30:46] php at abiusx dot com Valgrind gives me too many false positives to be usable. Yes, the crash does persist as I said before, so you are probably right. It's not zendMM fault. How can I increase the stack size, or something of the sort, or have a sighandler for stack overflow? Does stack overflow correlate with the size of the ZVALs in use by the program? Cuz only their references is pushed on the stack. ------------------------------------------------------------------------ [2016-05-24 18:28:43] nikic@php.net Just to make sure: Did you check that the crash is not caused by a stack overflow? You have dtrace enabled, so stack overflows are possible with simple function calls. You suspect a bug in the Zend MM. This can be easily verified by running the program with USE_ZEND_ALLOC=0 and seeing if the crash persists. Should the crash still occur, try running the program under "USE_ZEND_ALLOC=0 valgrind" and see if it prints any errors. ------------------------------------------------------------------------ [2016-05-24 18:15:49] php at abiusx dot com I re-implemented the same logic as a Zend Extension. The same crash happens at the same exact point. Using USE_ZEND_ALLOC=0 this is the error: php(21970,0x7fff75d48000) malloc: *** error for object 0x7fbc5c1ac960: pointer being freed was not allocated This is the exact same error whether I use pure PHP code or Zend extension code to do the same thing. Seems to depend on the size of the memory being utilized by the PHP process, if it is less than a certain threshold, it doesn't crash (but then crashes a few statemenets later in the same process, when only cutting out a few Kbytes). I am pretty certain at this point that there's an error in Zend Memory Manager, specially with regards to the way it handled zend objects in PHP 7. PHP 5+ are immune to this issue. ------------------------------------------------------------------------ [2016-05-24 18:15:42] php at abiusx dot com I re-implemented the same logic as a Zend Extension. The same crash happens at the same exact point. Using USE_ZEND_ALLOC=0 this is the error: php(21970,0x7fff75d48000) malloc: *** error for object 0x7fbc5c1ac960: pointer being freed was not allocated This is the exact same error whether I use pure PHP code or Zend extension code to do the same thing. Seems to depend on the size of the memory being utilized by the PHP process, if it is less than a certain threshold, it doesn't crash (but then crashes a few statemenets later in the same process, when only cutting out a few Kbytes). I am pretty certain at this point that there's an error in Zend Memory Manager, specially with regards to the way it handled zend objects in PHP 7. PHP 5+ are immune to this issue. ------------------------------------------------------------------------ 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