[Bug threads/28014] gdb coredumps when remote+kgdbing a system that OOMs too hard

["rincebrain at gmail dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28014

--- Comment #4 from Rich <rincebrain at gmail dot com> ---
(In reply to Simon Marchi from comment #3)
> (In reply to Rich from comment #2)
> > (In reply to Simon Marchi from comment #1)
> > > Hi Rich,
> > > 
> > > (In reply to Rich from comment #0)
> > > > I was using gdb on mips64el under qemu-user to remote a qemu of a mips64el
> > > > system with kgdb, everything was going fine (from gdb's perspective - the
> > > > system was in the process of eating all the RAM), then things went south.
> > > 
> > > Unrelated to the reported problem, but do you run GDB as a mips64el program
> > > inside qemu-user only so that you can debug your remote mips64el program? 
> > > It might be easier to run an x86-64 GDB (or whatever your host system is) to
> > > connect to your mips64el remote.  That GDB just needs to be built to include
> > > mips support, using --target=<your-triplet>, or
> > > --enable-targets=<your-triplet>, or --enable-targets=all.
> > 
> > Yeah, but recompiling gdb with all the arches I might need is a timesink
> > when I already had a chroot right there, and Debian's definitely doesn't
> > have other targets enabled OOTB.
> 
> No problem, I mentioned it just in case.
> 
> IIRC, this package is GDB built with --enable-targets=all:
> https://packages.debian.org/bullseye/gdb-multiarch.  So you could use it on
> a host Debian.  But if your setup works, it works.

That was what I assumed as well, but for at least this case, it errored in
precisely the same way as non-multiarch Debian. It's possible it would work for
local core dumps if not for, well, the other difficulties.

> > It's just the gdb binary from Debian bullseye at this precise moment:
> > https://www.dropbox.com/s/orf6tmcbctpjx16/gdb?dl=0
> > 
> > You may find this pretty useless, as none of my gdbs find the core useful,
> > and so far nobody in #qemu has known how to make use of it either.
> 
> Hmm, no success here either.  And I couldn't find debug info for that build
> in Debian's repos.
> 
> $ ./gdb -nx --data-directory=data-directory -q /tmp/gdb
> /tmp/qemu_gdb_20210625-192829_18450.core
> Reading symbols from /tmp/gdb...
> (No debugging symbols found in /tmp/gdb)
> 
> warning: core file may not match specified executable file.
> [New LWP 18450]
> [New LWP 18479]
> [New LWP 18480]
> Core was generated by ``/@   d/@   h/@   u/@   y/@  '.
> #0  0x0000004003148b4c in ?? ()
> [Current thread is 1 (LWP 18450)]
> (gdb) bt
> warning: GDB can't find the start of the function at 0x4003148b4c.
> 
>     GDB is unable to find the start of the function at 0x4003148b4c
> and thus can't determine the size of that function's stack frame.
> This means that GDB may be unable to access that stack frame, or
> the frames below it.
>     This problem is most likely caused by an invalid program counter or
> stack pointer.
>     However, if you think GDB should simply search farther back
> from 0x4003148b4c for code which looks like the beginning of a
> function, you can increase the range of the search using the `set
> heuristic-fence-post' command.
> #0  0x0000004003148b4c in ?? ()
> (gdb)

Yeah, that's about what I get.

I had no trouble finding the debug symbols from the debug symbol repo, though:

# apt install gdb-dbgsym
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following package was automatically installed and is no longer required:
  linux-image-5.10.0-6-5kc-malta
Use 'sudo apt autoremove' to remove it.
The following NEW packages will be installed:
  gdb-dbgsym
0 upgraded, 1 newly installed, 0 to remove and 8 not upgraded.
Need to get 21.3 MB of archives.
After this operation, 23.2 MB of additional disk space will be used.
Get:1 http://debug.mirrors.debian.org/debian-debug bullseye-debug/main mips64el
gdb-dbgsym mips64el 10.1-1.7 [21.3 MB]
Fetched 21.3 MB in 2s (9,234 kB/s)

Not that it helped...

# gdb `which gdb` qemu_gdb_20210625-192829_18450.core
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 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 "mips64el-linux-gnuabi64".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://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/bin/gdb...
Reading symbols from
/usr/lib/debug/.build-id/80/af60f6adb52cb6a14118a4fea3f9270ea1a923.debug...
[New LWP 18450]
[New LWP 18479]
[New LWP 18480]
Core was generated by ``�/@   d�/@   h�/@   u�/@   y�/@  '.
#0  0x0000004003148b4c in ?? (
warning: GDB can't find the start of the function at 0x4003148b4c.

    GDB is unable to find the start of the function at 0x4003148b4c
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x4003148b4c for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
)
[Current thread is 1 (LWP 18450)]
(gdb)

-- 
You are receiving this mail because:
You are on the CC list for the bug.