Edit report at https://bugs.php.net/bug.php?id=74877&edit=1
ID: 74877
User updated by: mcfedr at gmail dot com
Reported by: mcfedr at gmail dot com
Summary: Segmentation fault in zend_mm_alloc_small
Status: Open
Type: Bug
Package: Reproducible crash
Operating System: linux/macos
PHP Version: 7.2.0-beta1
Block user comment: N
Private report: N
New Comment:
This appears to have been fixed for me by a symfony update.
Previous Comments:
------------------------------------------------------------------------
[2017-07-31 15:35:22] as@php.net
I'd take a look if you can share the source code. Email if you'd like.
------------------------------------------------------------------------
[2017-07-24 08:24:13] mcfedr at gmail dot com
Ran with USE_ZEND_ALLOC=0 - Using php 7.2 the crash is more random now, happening in different
places
With valgrind and USE_ZEND_ALLOC=0 doesnt crash, reports lots of
==440== Conditional jump or move depends on uninitialised value(s)
==440== at 0x4082CB7: ???
==440== by 0xEEEB977: ???
==440== by 0xEEEB977: ???
==440== by 0xEEEB97B: ???
==440== by 0xFFEFFCA9F: ???
==440== by 0x3804FEEF: ??? (mc_malloc_wrappers.c:483)
==440==
==440== Conditional jump or move depends on uninitialised value(s)
==440== at 0x4082CE8: ???
==440== by 0x10C0C087: ???
==440== by 0x10C0C087: ???
==440== by 0x10C0C0B6: ???
==440== by 0xFFEFFCA9F: ???
==440== by 0x27: ???
With valgrind and without USE_ZEND_ALLOC=0
Lots of these:
==431== Conditional jump or move depends on uninitialised value(s)
==431== at 0x40AD424: ???
==431== by 0x22E82B7F: ???
==431== by 0x22E82B7F: ???
==431== by 0x22E82B8B: ???
==431== by 0xFFEFFC6DF: ???
==431== by 0x95015708B26750FF: ???
==431==
==431== Conditional jump or move depends on uninitialised value(s)
==431== at 0x40AAD5C: ???
==431== by 0x232FFE27: ???
==431== by 0x232FFE27: ???
==431== by 0x232FFE30: ???
==431== by 0xFFEFFC83F: ???
==431==
Then finishes with the segfault
==431== Invalid read of size 8
==431== at 0x58AA40: _emalloc (in /usr/local/bin/php)
==431== by 0x643899: ZEND_CONCAT_SPEC_TMPVAR_CV_HANDLER (in /usr/local/bin/php)
==431== by 0x659291: execute_ex (in /usr/local/bin/php)
==431== by 0x5A203B: zend_call_function (in /usr/local/bin/php)
==431== by 0x45D6A8: reflection_method_invoke (in /usr/local/bin/php)
==431== by 0x65F15A: execute_ex (in /usr/local/bin/php)
==431== by 0x65F7C3: zend_execute (in /usr/local/bin/php)
==431== by 0x5B21A2: zend_execute_scripts (in /usr/local/bin/php)
==431== by 0x54DB27: php_execute_script (in /usr/local/bin/php)
==431== by 0x661ABE: do_cli (in /usr/local/bin/php)
==431== by 0x261118: main (in /usr/local/bin/php)
==431== Address 0x2b1d018000 is not stack'd, malloc'd or (recently) free'd
==431==
==431==
==431== Process terminating with default action of signal 11 (SIGSEGV)
==431== Access not within mapped region at address 0x2B1D018000
==431== at 0x58AA40: _emalloc (in /usr/local/bin/php)
==431== by 0x643899: ZEND_CONCAT_SPEC_TMPVAR_CV_HANDLER (in /usr/local/bin/php)
==431== by 0x659291: execute_ex (in /usr/local/bin/php)
==431== by 0x5A203B: zend_call_function (in /usr/local/bin/php)
==431== by 0x45D6A8: reflection_method_invoke (in /usr/local/bin/php)
==431== by 0x65F15A: execute_ex (in /usr/local/bin/php)
==431== by 0x65F7C3: zend_execute (in /usr/local/bin/php)
==431== by 0x5B21A2: zend_execute_scripts (in /usr/local/bin/php)
==431== by 0x54DB27: php_execute_script (in /usr/local/bin/php)
==431== by 0x661ABE: do_cli (in /usr/local/bin/php)
==431== by 0x261118: main (in /usr/local/bin/php)
==431== If you believe this happened as a result of a stack
==431== overflow in your program's main thread (unlikely but
==431== possible), you can try to increase the size of the
==431== main thread stack using the --main-stacksize= flag.
==431== The main thread stack size used in this run was 8388608
==431==
==431== HEAP SUMMARY:
==431== in use at exit: 26,448,791 bytes in 459,135 blocks
==431== total heap usage: 4,214,628 allocs, 3,755,493 frees, 730,515,583 bytes allocated
==431==
==431== LEAK SUMMARY:
==431== definitely lost: 0 bytes in 0 blocks
==431== indirectly lost: 0 bytes in 0 blocks
==431== possibly lost: 1,635,452 bytes in 10,610 blocks
==431== still reachable: 24,813,339 bytes in 448,525 blocks
==431== suppressed: 0 bytes in 0 blocks
==431== Rerun with --leak-check=full to see details of leaked memory
==431==
==431== For counts of detected and suppressed errors, rerun with: -v
==431== Use --track-origins=yes to see where uninitialised values come from
==431== ERROR SUMMARY: 135 errors from 27 contexts (suppressed: 0 from 0)
Segmentation fault
------------------------------------------------------------------------
[2017-07-23 14:19:32] mcfedr at gmail dot com
Still reproduces with 7.2.0-beta1
------------------------------------------------------------------------
[2017-07-18 14:43:37] mcfedr at gmail dot com
Interesting idea that I meant to try, and now have. Exactly the same result. Seg fault in the same
place in the same test.
Clearly and issue with memory management, gc_disable and memory_limit=2G and all is fine
------------------------------------------------------------------------
[2017-07-18 13:32:55] schacht at kaliber5 dot de
Had exatly the same issue. Updating PHPUnit 4.x to 6.x (and dependent packages) solved this for me.
------------------------------------------------------------------------
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=74877
--
Edit this bug report at https://bugs.php.net/bug.php?id=74877&edit=1