From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C59E9385E02D; Sat, 26 Jun 2021 02:41:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C59E9385E02D From: "rincebrain at gmail dot com" To: gdb-prs@sourceware.org Subject: [Bug threads/28014] gdb coredumps when remote+kgdbing a system that OOMs too hard Date: Sat, 26 Jun 2021 02:41:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: threads X-Bugzilla-Version: 10.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rincebrain at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2021 02:41:54 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28014 --- Comment #4 from Rich --- (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, > > >=20 > > > (In reply to Rich from comment #0) > > > > I was using gdb on mips64el under qemu-user to remote a qemu of a m= ips64el > > > > 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. > > >=20 > > > Unrelated to the reported problem, but do you run GDB as a mips64el p= rogram > > > inside qemu-user only so that you can debug your remote mips64el prog= ram?=20 > > > 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=3D, or > > > --enable-targets=3D, or --enable-targets=3Dall. > >=20 > > 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. >=20 > No problem, I mentioned it just in case. >=20 > IIRC, this package is GDB built with --enable-targets=3Dall: > 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=3D0 > >=20 > > You may find this pretty useless, as none of my gdbs find the core usef= ul, > > and so far nobody in #qemu has known how to make use of it either. >=20 > Hmm, no success here either. And I couldn't find debug info for that bui= ld > in Debian's repos. >=20 > $ ./gdb -nx --data-directory=3Ddata-directory -q /tmp/gdb > /tmp/qemu_gdb_20210625-192829_18450.core > Reading symbols from /tmp/gdb... > (No debugging symbols found in /tmp/gdb) >=20 > 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. >=20 > 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, thou= gh: # 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 mips= 64el 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 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: . Find the GDB manual and other documentation resources online at: . 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 ``=EF=BF=BD/@ d=EF=BF=BD/@ h=EF=BF=BD/@ u=EF=BF= =BD/@ y=EF=BF=BD/@ '. #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) --=20 You are receiving this mail because: You are on the CC list for the bug.=