> I am sorry for not providing gdb backtrace, I don't really know
> how to do it properly.

See <https://bugs.php.net/bugs-generating-backtrace.php>.

cmb@php.net: That's exactly the page I was following. Still don't understand what I should do differently 
https://github.com/orisai/nette-console/commit/6a903996a84b3597455007938181a993d942c4df#diff-944291df2c9c06359d37cc8833d182d705c9e8c3108e7cfe132d61a06e9133ddR355-R358

In CI, I think you need to run gdb in batch mode e.g. like:

gdb -batch -ex "run" -ex "bt" --args /usr/bin/make coverage-clover

as that queues up the run and backtrace command.

I wasn't able to reproduce this locally (using nette-console). I used this command:

~/php/php-8.1/sapi/cli/php vendor/bin/paratest -c tools/phpunit.xml --runner=WrapperRunner -p32

Not seeing any warnings under valgrind either.

Danack at basereality dot com:
Thank you it seems to work now. Unfortunately it added only this to output

> [Inferior 1 (process 3171) exited with code 02]
> No stack.

https://github.com/orisai/nette-console/runs/4188618661?check_suite_focus=true#step:13:117


nikic@php.net:
My full command was this, hopefully it will be helpful
XDEBUG_MODE=off php -d pcov.enabled=1 -d pcov.directory=./src "vendor/bin/paratest" -c tools/phpunit.xml --runner=WrapperRunner -p16 --coverage-clover=var/coverage/clover.xml

Would it be possible to test with pcov not enabled? Looking at the bug tracker there, https://github.com/krakjoe/pcov/issues/73 seems to indicate that there may be a compatibility issue between pcov and PHP 8.1.

nikic@php.net:
That's it! Thank you, I had no idea it could be caused by pcov.
https://github.com/orisai/nette-console/runs/4188901103?check_suite_focus=true#step:13:99

Testing with pcov now, I see this valgrind warning:

==1363300== Invalid read of size 4
==1363300==    at 0x8535BA: zend_string_release (zend_string.h:319)
==1363300==    by 0x853AB4: zm_deactivate_filestat (filestat.c:91)
==1363300==    by 0x828BFB: zm_deactivate_basic (basic_functions.c:541)
==1363300==    by 0xA3AF67: zend_deactivate_modules (zend_API.c:3016)
==1363300==    by 0x98B198: php_request_shutdown (main.c:1823)
==1363300==    by 0xB9FE2A: do_cli (php_cli.c:1135)
==1363300==    by 0xBA06FF: main (php_cli.c:1367)
==1363300==  Address 0xbc7b2b4 is 4 bytes inside a block of size 91 free'd
==1363300==    at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==1363300==    by 0x66632B: php_pcov_filename_dtor (pcov.c:345)
==1363300==    by 0xA47E82: zend_hash_destroy (zend_hash.c:1590)
==1363300==    by 0x666952: zm_deactivate_pcov (pcov.c:493)
==1363300==    by 0xA3AF67: zend_deactivate_modules (zend_API.c:3016)
==1363300==    by 0x98B198: php_request_shutdown (main.c:1823)
==1363300==    by 0xB9FE2A: do_cli (php_cli.c:1135)
==1363300==    by 0xBA06FF: main (php_cli.c:1367)
==1363300==  Block was alloc'd at
==1363300==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==1363300==    by 0x665E91: php_pcov_interned_string (pcov.c:210)
==1363300==    by 0x665F21: php_pcov_create (pcov.c:232)
==1363300==    by 0x6660D1: php_pcov_trace (pcov.c:270)
==1363300==    by 0x66625D: php_pcov_execute_ex (pcov.c:323)
==1363300==    by 0xA6B99A: ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER (zend_vm_execute.h:1728)
==1363300==    by 0xAE4218: zend_vm_call_opcode_handler (zend_vm_execute.h:62999)
==1363300==    by 0x666117: php_pcov_trace (pcov.c:282)
==1363300==    by 0x66625D: php_pcov_execute_ex (pcov.c:323)
==1363300==    by 0xA6BDE1: ZEND_DO_FCALL_SPEC_RETVAL_USED_HANDLER (zend_vm_execute.h:1837)
==1363300==    by 0xAE4218: zend_vm_call_opcode_handler (zend_vm_execute.h:62999)
==1363300==    by 0x666117: php_pcov_trace (pcov.c:282)

https://github.com/krakjoe/pcov/pull/75 fixes the issue for me.

This is a pcov bug, not a PHP one.
It has been fixed in pcov.
Thanks for your report.