On KDE Linux, how can I get a stack trace with debug symbols?

Help
1

I’m trying to get a stack trace with debug symbols for a kwin_wayland crash that I’m reproducibly experiencing on KDE Linux.

As I understand it on KDE Linux (and on Arch-based distros in general), the symbols should come from debuginfod.

When I run sudo coredumpctl gdb 1930 (where 1930 happens to be the PID for crashed process), gdb didn’t prompt me to download debug symbols, and I got a stack trace full of unhelpful n/a - the following is a short excerpt.

       Message: Process 1930 (kwin_wayland) of user 1000 dumped core.
                
                Stack trace of thread 1930:
                #0  0x00007f298952129c n/a (libc.so.6 + 0x9a29c)
                #1  0x00007f29894c57d0 raise (libc.so.6 + 0x3e7d0)
                #2  0x00007f298c574469 _ZN6KCrash19defaultCrashHandlerEi (libKF6Crash.so.6 + 0x5469)
                #3  0x00007f29894c58f0 n/a (libc.so.6 + 0x3e8f0)
                #4  0x00007f298a3547f8 _ZNK12KConfigGroup6configEv (libKF6ConfigCore.so.6 + 0x367f8)
                #5  0x00007f298a355231 _ZNK12KConfigGroup9readEntryEPKcRK7QString (libKF6ConfigCore.so.6 + 0x37231)
                #6  0x00007f298b5794c2 n/a (libKGlobalAccelD.so.0 + 0x264c2)
                #7  0x00007f298b566473 n/a (libKGlobalAccelD.so.0 + 0x13473)
                #8  0x00007f298b5666b3 n/a (libKGlobalAccelD.so.0 + 0x136b3)

To try t get the symbols to be downloaded, I then:

  1. Created file ~/.gdbinit with content set debuginfod enabled on
  2. Created file /root/.config/gdb/gdbinit with content add-auto-load-safe-path /home/myusername/.gdbinit

But after this, sudo coredumpctl gdb 1930 had exactly the same result. It didn’t appear to try downloading anything, and the output was the same.

Before all this, I’d tried to use DrKonqi to get the crash dump (like this user who asked a similar question). DrKonqi did appear to try to download symbols, but got into an endless loop where it reported attempting to download the same files over and over again.

What am I missing?

2

Hmm, this sounds like a bug. Does it still break if you try it again?

Also you may need to run coredumpctl with run0 if the crash is from kwin_wayland. Does that help?

3

If you’re going to use sudo with the coredump comman, maybe try the following:

sudo -E coredumpctl gdb pid

That will preserve your environment so that everything is still available to gdb

4

Unfortunately I can’t find a way to reproduce this now. The bug that crashed kwin_wayland seems to be fixed in Plasma 6.8, so I can’t recreate it in the newest KDE Linux images. The oldest image I have (20260518) does pre-date the fix, but now if I try to boot into that I’m thrown into emergency mode.

Maybe we have to just park this until I next get a kwin_wayland crash? (Unless there’s a known way of producing one?)

Aha! I used this on a core dump from a different issue, and adding the -E was what made the difference to get a proper stack trace.

Thank you!

Sounds like we should edit the wiki page to add the -E. Any objections if I do this?

5

Sure, go ahead!

6

Cool, updated the wiki!

7

Just to follow up on this point, I think this is an artefact of logging rather than a genuine issue.

DrKonqi does eventually get the stack trace, but it looks like each time it downloads a file, it repeats the “Downloading…” log items for the previously downloaded files.