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

["simark at simark dot ca" <sourceware-bugzilla@sourceware.org>]

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

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simark at simark dot ca

--- Comment #1 from Simon Marchi <simark at simark dot ca> ---
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.

> The kernel reported, after a whole bunch of other screaming:
> [59702.844702] Out of memory and no killable processes...
> [59702.845130] Kernel panic - not syncing: System is deadlocked on memory
> 
> Meanwhile, when I tabbed back over, gdb said:
> [New Thread 172398]
> [New Thread 172401]
> [New Thread 172402]
> [New Thread 172403]
> [New Thread 172404]
> [New Thread 172405]
> --Type <RET> for more, q to quit, c to continue without paging--
> 
> Thread 2 received signal SIGTRAP, Trace/breakpoint trap.
> [Switching to Thread 1]
> /build/gdb-OSO7kB/gdb-10.1/gdb/thread.c:95: internal-error: thread_info*
> inferior_thread(): Assertion `current_thread_ != nullptr' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Quit this debugging session? (y or n) y
> 
> This is a bug, please report it.  For instructions, see:
> <https://www.gnu.org/software/gdb/bugs/>.
> 
> /build/gdb-OSO7kB/gdb-10.1/gdb/thread.c:95: internal-error: thread_info*
> inferior_thread(): Assertion `current_thread_ != nullptr' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Create a core file of GDB? (y or n) y
> qemu: uncaught target signal 6 (Aborted) - core dumped
> Aborted
> 
> 
> And so I'm here.
> 
> (I won't be astonished if you just close this with "everything was on fire,
> what are you expecting", but since gdb did request I open a bug, here I am.)

I presume that the remote connection (what kind of connection was that, tcp?)
closed at an unexpected time.  GDB is not very good at handling that
gracefully.  

It might not be a bug somebody will immediately jump to fix, but every time you
hit a GDB internal error, you can consider it a valid GDB bug.  It should never
be possible for a user to hit an internal error, whatever the bad input they
provide (including a remote connection breaking at an unexpected moment).  

> Since the core is 80M compressed and 236M uncompressed, you can find it:
> https://www.dropbox.com/s/u7erpk1x6fj4ds6/qemu_gdb_20210625-192829_18450.
> core.zst?dl=0

There's little we can do without the gdb executable that goes along with the
core file.  Can you provide that too?  If we can get a good backtrace of GDB,
at least we'll be able to rough idea.

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