Bug #77922 [Com]: Segmentation fault in PHP 7.3.4 when running phpunit

Edit report at https://bugs.php.net/bug.php?id=77922&edit=1 ID: 77922 Comment by: andrew at nicols dot co dot uk Reported by: enumag at gmail dot com Summary: Segmentation fault in PHP 7.3.4 when running phpunit Status: Open Type: Bug Package: Unknown/Other Function Operating System: Ubuntu PHP Version: 7.3.4 Block user comment: N Private report: N New Comment: We're now seeing this on every full phpunit run with MySQL on PHP 7.2 and PHP 7.3 (using latest apache docker images). What can we do to help this issue get some attention? Previous Comments: ------------------------------------------------------------------------ [2019-07-30 23:27:13] andrew at nicols dot co dot uk We are still seeing this in a repeatable fashion on PHP 7.3.7, only it has now progressed from hitting just SQLServer to MySQLi too. Have a coredump, and will generate valgrind if it's useful. As others have said, only happens on a full run. Moodle (same as stronk7) ------------------------------------------------------------------------ [2019-06-03 14:29:52] stronk7 at moodle dot com Just for the records, we are also facing a similar problem with PHP 7.3 and our phpunit tests.The very same stuff passes without problems with 7.1 and 7.2. Have been able to consistently reproduce the problem both with debian9 (dockerized) and macos x mojave. ........................................................... 7906 / 13354 ( 59%) ...Segmentation fault: 11 (`core' generado) In our case, it's curious because the problem is only reproducible when we are using the sqlsrv extension (tests are passing perfectly with any other db), but this maybe a factor, not the cause, as far as our backtrace is pretty similar the originally reported here (mac one follows): (lldb) bt all * thread #1, stop reason = signal SIGSTOP * frame #0: 0x0000000109da5ade php`zend_mm_alloc_small + 206 frame #1: 0x0000000109da304d php`zend_mm_alloc_heap + 301 frame #2: 0x0000000109da3fe6 php`_emalloc + 182 frame #3: 0x0000000109d9481c php`zend_string_alloc + 124 frame #4: 0x0000000109d7fecf php`zend_string_init + 31 frame #5: 0x0000000109d82488 php`lex_scan + 3000 frame #6: 0x0000000109dab4c4 php`zendlex + 68 frame #7: 0x0000000109d787ee php`zendparse + 878 frame #8: 0x0000000109d8090c php`zend_compile + 92 frame #9: 0x0000000109d80882 php`compile_file + 146 frame #10: 0x0000000109ad1fa4 php`phar_compile_file + 1204 frame #11: 0x0000000109d80b6a php`compile_filename + 218 frame #12: 0x0000000109ee7484 php`zend_include_or_eval + 884 frame #13: 0x0000000109e80a6f php`ZEND_INCLUDE_OR_EVAL_SPEC_TMPVAR_HANDLER + 63 frame #14: 0x0000000109e54434 php`execute_ex + 100 frame #15: 0x0000000109dc956a php`zend_call_function + 2826 frame #16: 0x0000000109e435d7 php`zend_std_call_getter + 247 frame #17: 0x0000000109e42cb6 php`zend_std_read_property + 1350 frame #18: 0x0000000109e89268 php`ZEND_FETCH_OBJ_R_SPEC_CV_CONST_HANDLER + 1928 frame #19: 0x0000000109e54434 php`execute_ex + 100 frame #20: 0x0000000109e5463a php`zend_execute + 234 frame #21: 0x0000000109de6fa2 php`zend_execute_scripts + 594 frame #22: 0x0000000109d39103 php`php_execute_script + 1139 frame #23: 0x0000000109ef5440 php`do_cli + 3440 frame #24: 0x0000000109ef4401 php`main + 1633 frame #25: 0x00007fff785543d5 libdyld.dylib`start + 1 frame #26: 0x00007fff785543d5 libdyld.dylib`start + 1 Also, like the original reporter... the fault only happens when we run all the tests, running only the "breaking" one doesn't break. And taking rid of the "breaking" one makes the whole run to pass. So, we know it only happens for us with sqlsrv, we know which exact test case causes it (pretty innocent one, I'd say) and it's only reproducible running all tests. Not sure if all the above helps, but that's what we have been able to find till now, so far. Ciao :-) ------------------------------------------------------------------------ [2019-05-21 10:09:02] wskorodecki at gmail dot com I'm facing the same problem on PHP 7.3.5 on Archlinux but my stacktrace is different. Interesting here is that the error does not occur when I execute "phpunit -v" outside our Symfony-based project, that has a "tests" directory containing several tests based on PHPUnit. $ php -v PHP 7.3.5 (cli) (built: Apr 30 2019 21:05:09) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.3.5, Copyright (c) 1998-2018 Zend Technologies with Zend OPcache v7.3.5, Copyright (c) 1999-2018, by Zend Technologies $ phpunit --version PHPUnit 8.0.1 by Sebastian Bergmann and contributors. $ php -m [PHP Modules] Core ctype curl date dom ds fileinfo filter ftp gd hash iconv igbinary intl json libxml mbstring mysqlnd odbc openssl pcntl pcre PDO pdo_mysql pdo_sqlite Phar posix readline redis Reflection session SimpleXML soap SPL standard tokenizer xml xmlreader xmlwriter Zend OPcache zip zlib [Zend Modules] Zend OPcache $ phpunit -v Segmentation fault (core dumped) $ coredumpctl info 20528 PID: 20528 (php) UID: 1000 (wojtek) GID: 985 (users) Signal: 11 (SEGV) Timestamp: Tue 2019-05-21 08:26:09 CEST (42s ago) Command Line: php /usr/local/bin/phpunit -v Executable: /usr/bin/php Control Group: /user.slice/user-1000.slice/session-2.scope Unit: session-2.scope Slice: user-1000.slice Session: 2 Owner UID: 1000 (wojtek) Boot ID: 526298d71d1a4cb6bf2294d12eea5611 Machine ID: f372dea6fef44dc1ad344b6b92e63878 Hostname: archlinux-ws Storage: /var/lib/systemd/coredump/core.php.1000.526298d71d1a4cb6bf2294d12eea5611.20528.1558419969000000.lz4 Message: Process 20528 (php) of user 1000 dumped core. Stack trace of thread 20528: #0 0x000055e6a0409bd0 n/a (php) #1 0x000055e6a05857c5 execute_ex (php) #2 0x000055e6a058b836 zend_execute (php) #3 0x000055e6a050455a zend_execute_scripts (php) #4 0x000055e6a04a4489 php_execute_script (php) #5 0x000055e6a058de36 n/a (php) #6 0x000055e6a028f067 n/a (php) #7 0x00007f51c5576ce3 __libc_start_main (libc.so.6) #8 0x000055e6a028f74e _start (php) ------------------------------------------------------------------------ [2019-05-04 09:21:39] enumag at gmail dot com Note: This bug still exists in PHP 7.3.5. ------------------------------------------------------------------------ [2019-04-24 18:59:02] enumag at gmail dot com How do we fix it then? Is there anything else I can do to help? This is currently blocking us from upgrading to PHP 7.3. ------------------------------------------------------------------------ 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=77922 -- Edit this bug report at https://bugs.php.net/bug.php?id=77922&edit=1