Re: please help fixing php-fpm on armv7 - egdb result

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: please help fixing php-fpm on armv7 - egdb result

s_graf
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)

-----Original Message-----
From: [hidden email] <[hidden email]> On Behalf Of Jeremie Courreges-Anglas
Sent: January 11, 2019 6:12 AM
To: [hidden email]
Cc: [hidden email]; [hidden email]
Subject: Re: please help fixing php-fpm on armv7

On Mon, Jan 07 2019, <[hidden email]> wrote:

> I would like to get php-fpm working again on arm.  The last time I had a
> working version was Aug.
> I can build the port, run debug and report crash dumps but do not have the
> expertise to analyse the code.
> Any and all help is appreciated.  I will do what I can under guidance.
>
> First, I would like to know if anyone else has experienced this problem, or
> am I the only one.
> My system is an orangepi one (Allwinner H3).
>
> The build I am testing with is a snapshot kernel of Dec 28 and ports of Jan
> 1.
> The problem I reported with building libffi  on the Dec 28 ports did not
> reoccur on the Jan 1 ports.
>
> I configured php with as much debug as I could and ran it non-daemon for a
> console debug log and then as a daemon to get a core.
> Attached is the console log and core backtrace.

The gdb backtrace below is unusable, this happens on archs that
moved to clang.  Please use egdb from the gdb package.

> op1bsdsnap1228# gdb /usr/local/sbin/php-fpm-7.2 /root/php-fpm-7.2.core
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "arm-unknown-openbsd6.4"...(no debugging symbols found)
>
> Core was generated by `php-fpm-7.2'.
> Program terminated with signal 11, Segmentation fault.
> (no debugging symbols found)
> Loaded symbols for /usr/local/sbin/php-fpm-7.2
> Reading symbols from /usr/local/lib/libsodium.so.9.1...done.
> Loaded symbols for /usr/local/lib/libsodium.so.9.1
> Reading symbols from /usr/lib/libreadline.so.4.0...done.
> Loaded symbols for /usr/lib/libreadline.so.4.0
> Reading symbols from /usr/lib/libcurses.so.14.0...done.
> Loaded symbols for /usr/lib/libcurses.so.14.0
> Reading symbols from /usr/local/lib/libonig.so.5.0...done.
> Loaded symbols for /usr/local/lib/libonig.so.5.0
> Reading symbols from /usr/local/lib/libiconv.so.6.0...done.
> Loaded symbols for /usr/local/lib/libiconv.so.6.0
> Reading symbols from /usr/local/lib/libintl.so.6.0...done.
> Loaded symbols for /usr/local/lib/libintl.so.6.0
> Reading symbols from /usr/lib/libz.so.5.0...done.
> Loaded symbols for /usr/lib/libz.so.5.0
> Reading symbols from /usr/lib/libm.so.10.1...done.
> Loaded symbols for /usr/lib/libm.so.10.1
> Reading symbols from /usr/local/lib/libxml2.so.16.1...done.
> Loaded symbols for /usr/local/lib/libxml2.so.16.1
> Reading symbols from /usr/local/lib/liblzma.so.2.1...done.
> Loaded symbols for /usr/local/lib/liblzma.so.2.1
> Reading symbols from /usr/lib/libssl.so.47.1...done.
> Loaded symbols for /usr/lib/libssl.so.47.1
> Reading symbols from /usr/lib/libcrypto.so.45.1...done.
> Loaded symbols for /usr/lib/libcrypto.so.45.1
> Reading symbols from /usr/lib/libpthread.so.25.1...done.
> Loaded symbols for /usr/lib/libpthread.so.25.1
> Reading symbols from /usr/lib/libc.so.93.0...done.
> Loaded symbols for /usr/lib/libc.so.93.0
> Reading symbols from /usr/libexec/ld.so...done.
> Loaded symbols for /usr/libexec/ld.so
> #0  0xdfdfdfdc in ?? ()
> (gdb)

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE


Reply | Threaded
Open this post in threaded view
|

Re: please help fixing php-fpm on armv7 - egdb result

Stuart Henderson
On 2019/01/12 16:41, Karel Gardas wrote:

> On Fri, 11 Jan 2019 17:02:25 -0800
> <[hidden email]> 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)..