> I'm encountering a SIGSEGV in PHP-FPM on PHP 7.4.2 in a Symfony app. The
> bug seems to happen during the rendering of a Twig template; this makes it
> hard for me to pinpoint the code that triggers the segfault.
> Could you please tell me what the procedure to collect information is, so
> that I can file a useful bug report?
I'm not sure if there are official recommendations, but what I've done before for httpd:
1. Do you have a line in your syslogs (e.g. /var/log/messages or elsewhere for ip (instruction pointer) segfaulted in libphp7.so or elsewhere, etc. If you run objdump --disassemble-all on the shared library where the crash occurs, you might know slightly more, but not very much, and would want to generate a core dump instead.
For something like "segfault at ffffffff00000008 ip 00007f2ca2ef7121 sp 00007ffeef578850 error 5 in libphp7.so[7f2ca2a83000+b95000]", it'd have crashed at the instruction on 0x00007f2ca2ef7121 - 0x7f2ca2a83000 in libphp7.so
2. I haven't tried these instructions before, but you probably want to enable core dumps. https://ma.ttias.be/generate-php-core-dumps-segfaults-php-fpm/ (first google result) may help.
Then, you can run 'gdb /usr/local/php/modules/libphp7.so /tmp/coredumpxxx' to see the stack trace where the dump occurred to include it, and include it in a bug report. (the path or shared library you want may differ)
If you can install debugging symbols (I'm not sure what the package is called - something like php-debuginfo or running debuginfo-install ....?), or build php with --enable-debug and reproduce the crash, that would also help.
Make sure to turn off core dumps and restart php-fpm when you're done.
Using a build of php configured with --enable-debug would also tell you if a ZEND_ASSERT failed before the segmentation fault (I think, I forget how it works with fpm)