Edit report at https://bugs.php.net/bug.php?id=72144&edit=1
ID: 72144
Comment 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:
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.
Previous Comments:
------------------------------------------------------------------------
[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)?
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
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