Bug #78280 [Opn]: _emalloc causes segfaults

From: Date: Mon, 15 Jul 2019 11:53:44 +0000
Subject: Bug #78280 [Opn]: _emalloc causes segfaults
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-221781@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=78280&edit=1 ID: 78280 Updated by: nikic@php.net Reported by: grzegorz129 at gmail dot com Summary: _emalloc causes segfaults Status: Open Type: Bug Package: Reproducible crash Operating System: Linux PHP Version: 7.3.7 Block user comment: N Private report: N New Comment: Can you please check whether the current PHP 7.3 head (that includes the fix for bug #78010) resolves your issue? Previous Comments: ------------------------------------------------------------------------ [2019-07-12 18:50:46] nikic@php.net Unassigning Joe as this is GNU parallel, not ext/parallel ^^ The valgrind traces look very similar to bug #78010, which has a small repro. Maybe fixing that will fix your case as well. ------------------------------------------------------------------------ [2019-07-12 18:45:46] grzegorz129 at gmail dot com I just got a very interesting crash on non-debug version of php with no parallelism or anything, just a simple command and it produced such trace: #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007fe63d389801 in __GI_abort () at abort.c:79 #2 0x00007fe63d3d2897 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7fe63d4ffb9a "%s\n") at ../sysdeps/posix/libc_fatal.c:181 #3 0x00007fe63d3d990a in malloc_printerr (str=str@entry=0x7fe63d5013f0 "malloc_consolidate(): invalid chunk size") at malloc.c:5350 #4 0x00007fe63d3d9bae in malloc_consolidate (av=av@entry=0x7fe63d734c40 <main_arena>) at malloc.c:4441 #5 0x00007fe63d3e103b in _int_free (have_lock=0, p=<optimized out>, av=0x7fe63d734c40 <main_arena>) at malloc.c:4362 #6 __GI___libc_free (mem=0x563df37a0d10) at malloc.c:3124 #7 0x0000563df15b8e41 in zend_hash_destroy (ht=ht@entry=0x563df3762438) at ./Zend/zend_hash.c:1461 #8 0x0000563df159e1de in destroy_zend_class (zv=zv@entry=0x563df3341cc0) at ./Zend/zend_opcode.c:247 #9 0x0000563df159a730 in shutdown_executor () at ./Zend/zend_execute_API.c:345 #10 0x0000563df15a8efb in zend_deactivate () at ./Zend/zend.c:1104 #11 0x0000563df1547cbf in php_request_shutdown (dummy=<optimized out>) at ./main/main.c:1926 #12 0x0000563df1639ae4 in do_cli (argc=6, argv=0x563df22563b0) at ./sapi/cli/php_cli.c:1164 #13 0x0000563df140090b in main (argc=6, argv=0x563df22563b0) at ./sapi/cli/php_cli.c:1389 ------------------------------------------------------------------------ [2019-07-12 18:27:54] grzegorz129 at gmail dot com And another valgrind output: https://pastebin.com/KVBjEeq5 ------------------------------------------------------------------------ [2019-07-12 17:45:26] grzegorz129 at gmail dot com As expected it crashed. The valgrind output still has a lot of "??"s but I'm not sure if that's expected: https://pastebin.com/ygvC5aws ------------------------------------------------------------------------ [2019-07-12 17:13:39] grzegorz129 at gmail dot com Re-running with the options provided. After disabling opcache the result is the same. In fact I've got one crash after just seconds of running which is very short: https://pastebin.com/zxefix13 Another one took longer but crashed again: https://pastebin.com/hsC6nqGn So I think opcache is not a factor here. To be precise about parallel it's not a parallelized on php level, but rather run with GNU Parallel. ------------------------------------------------------------------------ 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=78280 -- Edit this bug report at https://bugs.php.net/bug.php?id=78280&edit=1

« previous php.bugs (#221781) next »