On 2019/01/12 16:41, Karel Gardas wrote: > On Fri, 11 Jan 2019 17:02:25 -0800 > <s_g...@telus.net> wrote: > > > Thank you Jeremie for your suggestion. I built the gdb package and ran > > egdb with the result below. I hope this provides some clues. > > > > op1bsdsnap1228# egdb /usr/local/sbin/php-fpm-7.2 /root/php-fpm-7.2.core > > GNU gdb (GDB) 7.12.1 > > Copyright (C) 2017 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later > > <http://gnu.org/licenses/gpl.html> > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > > and "show warranty" for details. > > This GDB was configured as "arm-unknown-openbsd6.4". > > Type "show configuration" for configuration details. > > For bug reporting instructions, please see: > > <http://www.gnu.org/software/gdb/bugs/>. > > Find the GDB manual and other documentation resources online at: > > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > > Type "apropos word" to search for commands related to "word"... > > Reading symbols from /usr/local/sbin/php-fpm-7.2...(no debugging symbols > > found)...done. > > [New process 446218] > > > > warning: .dynamic section for "/usr/lib/libcrypto.so.45.1" is not at the > > expected address (wrong library or version mismatch?) > > > > warning: .dynamic section for "/usr/lib/libc.so.93.0" is not at the > > expected address (wrong library or version mismatch?) > > Core was generated by `php-fpm-7.2'. > > Program terminated with signal SIGSEGV, Segmentation fault. > > #0 0xdfdfdfde in ?? () > > (gdb) > > Here ^ you should type "bt" and hit Enter and this way you will see > stacktrace of the crash. Also if you build php-fpm-7.2 with debugging > enabled, it will help too probably since you will/should see line numbers etc.
That is not how a healthy stack looks. It's highly unlikely you will get anything useful from a backtrace of this coredump. I think it's likely to need one or a combination of: - enable as much debug logging as possible - add extra debugging logs/printfs - running from the start under a debugger and stepping through to figure out codepaths leading to the crash to try to figure out what's going on. I'd take a look if I had hardware though I don't know if I would be able to figure it out (I haven't got anywhere with the php-7.3 crashfest on OpenBSD/amd64 either)..
