[HN Gopher] Inspecting coredumps like it's 2021
___________________________________________________________________
Inspecting coredumps like it's 2021
Author : ingve
Score : 58 points
Date : 2021-09-20 18:17 UTC (4 hours ago)
(HTM) web link (nixos.mayflower.consulting)
(TXT) w3m dump (nixos.mayflower.consulting)
| seiferteric wrote:
| This brings up a question I have had, is it not possible to put
| the debug info in a separate file that gdb could load instead of
| in the binary itself? If you could do this, you could then easily
| have xyz-dbg packages that only contained these files, or even an
| distro repository of these files that the debugger could download
| as needed.
| AshamedCaptain wrote:
| This is exactly what most distributions do these days.
|
| The debug symbol packages are usually called -dbgsym (Ubuntu,
| Debian, ...) or -debuginfo (openSUSE, Fedora).
|
| This has been done automatically for almost a decade in most
| distros' packaging systems. GDB usually tells you what are the
| names of the debug packages you need to install for whatever
| you are trying to debug.
|
| The "distro repository of files that the debugger can download
| as needed" is called a debuginfod URL. E.g., for Debian :
| https://debuginfod.debian.net/ , openSUSE :
| https://debuginfod.opensuse.org/ , etc. This is a more recent
| development and distros are just starting to turn it on by
| default. But if enabled you'll basically see GDB start
| downloading symbol files automatically ala Windows when you run
| it. It even downloads the source code as it goes.
|
| Personally I think the latter is a security risk (since it
| sends to a server the hash/build-id of everything you try to
| debug), but I can't argue it's not convenient.
| gtirloni wrote:
| Like this? https://access.redhat.com/solutions/9907
| stefan_ wrote:
| If you are in control of your build, ideally you want to embed
| build IDs and use a symbol server. Here is an older article
| from Bruce Dawson on this (unfortunately way underdeveloped)
| area of Linux:
|
| https://randomascii.wordpress.com/2013/02/20/symbols-on-linu...
| 10000truths wrote:
| Yes. You can separate the debug info from an object file with
| objcopy: objcopy --only-keep-debug foo.o
| foo.o.debug objcopy --strip-debug --add-gnu-
| debuglink=foo.o.debug foo.o
|
| And then link foo.o as normal. GDB should automatically be able
| to pick up the debug file by looking at the debug link.
|
| For more info, here's a link:
|
| https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Fil...
|
| You can also use gcc's -gsplit-dwarf command line option when
| compiling to produce a .dwo file containing your debug
| information:
|
| https://gcc.gnu.org/wiki/DebugFission
| [deleted]
| donio wrote:
| So I guess it's still using gdb like it's 1999.
| kragen wrote:
| gdb has changed a lot since 01999.
| Joker_vD wrote:
| One day we may get a vim or even emacs mode for gdb, who knows?
| Until then, I will continue to "enjoy" interacting with the
| data of the program under debugger in the ed-style, like a True
| Programmer(tm).
|
| The stories have it that back in the days some people could
| read actual core dumps with the tips of their fingers a la
| Braille, but surely that's just an urban myth.
| AshamedCaptain wrote:
| GDB has a GUI (TUI). Several, in fact...
| Arnavion wrote:
| Indeed, and coredumpctl can be told to pass `--tui` to the
| gdb invocation with `-A --tui`
|
| Also you can use another debugger of your choice with the
| `--debugger` flag.
| [deleted]
| jandrese wrote:
| Was anybody else disappointed that it's still just gdb for the
| debugger? I've thought for a long time that something better must
| be out there, especially a debugger that better handles multiple
| threads in an application, but every time I need to debug
| something I'm back in the 80s.
| AshamedCaptain wrote:
| What would be better? How to improve the handling of multiple
| threads?
|
| Every time I have tried a different debugger, I have always
| ended up coming running back to GDB. My only gripes with it are
| basically gripes with DWARF.
| bsdubernerd wrote:
| What about lldb? Has anybody had extensive experience with both
| to say anything about the actual debugging experience? Does it
| offer anything more than just "infrastructure"?
| tazjin wrote:
| Same basic concept, though it had some nicer representations
| of non-C language things OOB when I tried it.
| selfhoster11 wrote:
| Really, my kingdom for a debugger that is as accessible as the
| one from IntelliJ.
| astange wrote:
| The CLion front end to gdb/lldb is very good. Not perfect,
| but that's mainly do the oddities of interacting with the
| underlying debugger.
|
| https://www.jetbrains.com/help/clion/debugging-code.html
| xxpor wrote:
| I don't get what it's missing other than a GUI. I can view
| stacktraces, view memory in various formats, create new
| commands on the fly or in .gdbinit... what are people missing?
| [deleted]
| tom_ wrote:
| Well I miss a GUI.
| hyperman1 wrote:
| I see a lot of sudo in there, for debugging a program presumably
| not running as root. Is it possible with this tooling to debug
| core dumps as a normal user?
| necrotic_comp wrote:
| I agree, that seems like a very bad idea.
| pengaru wrote:
| sudo should not be required if the coredumped process was
| running as your user, but this will only be true if systemd was
| built with +ACL (look at `systemctl --version` output).
| jandrese wrote:
| Systemd's core dump utility stuffs the files in
| /var/lib/systemd/coredump with 640 permissions and ownership of
| root:root regardless of who owned the process.
|
| It might be paranoia on someone's part, but I agree that it
| causes a lot of unnecessary privilege escalation for people who
| want to actually fix the problem.
| rwmj wrote:
| This isn't true, at least on Fedora. When my program crashes
| I run "coredumpctl gdb" without sudo and it works fine - I
| use this all the time.
|
| (It could be that Fedora has done some special configuration
| and that it's not like this out of the box for upstream
| systemd)
| e12e wrote:
| I'm not at my laptop right now, but from https://www.freede
| sktop.org/software/systemd/man/coredumpctl...
|
| It looks like coredumpctl might be suid? Or that the
| service is, and coredumpctl gets access through the service
| - so there's a certain elevation going on either way?
| lights0123 wrote:
| It's not. It sets ACLs so that the user that owns the
| process may read the coredump, but typical ls doesn't
| show that.
| jcelerier wrote:
| .. but you can just run coredumpctl gdb or coredumpctl dump
| <the dump> > /tmo/YOLO.dump
| pengaru wrote:
| > Systemd's core dump utility stuffs the files in
| /var/lib/systemd/coredump with 640 permissions and ownership
| of root:root regardless of who owned the process.
|
| This isn't true for +ACL builds of systemd, look at the
| output of `getfacl /var/lib/systemd/coredump/$foo` and you'll
| see.
| waynesonfire wrote:
| i love the attempt here but isn't 2021 all about containers? does
| k8s even generate coredumps? lol. what a joke.
| cardy31 wrote:
| K8s can generate coredumps if you configure it to, and they can
| actually still be useful in debugging certain classes of
| problems! However, at the multi-thousand person company I work
| at, there is like one guy concerned with core dumps.
| richardwhiuk wrote:
| Does Nix really not have debug symbols available for most
| packages? That's astonishing....
| er4hn wrote:
| One feature of Nix is to be able to rebuild something the same
| way on different systems. The article suggests that adding the
| debug symbols is a simple flag in the build expression.
|
| Based on that, you shouldn't need the debug symbols in advance,
| though ymmv, when trying to debug an issue in container A on
| dev machine B.
| outworlder wrote:
| Nix is the package manager. NixOS is the OS.
|
| It's very common to strip debug symbols from packages. For
| Ubuntu, it's even a different repository! I fail to see why
| that's astonishing.
| whateveracct wrote:
| People can be astonished by anything if they didn't ask the
| right questions before spouting answers :)
| kingforaday wrote:
| I think standard practice is to strip the binary before
| release.
___________________________________________________________________
(page generated 2021-09-20 23:00 UTC)