> 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) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
