Ancestors

Toot

Written by Andrew Helwer on 2025-01-11 at 21:42

Does anybody know a tutorial for debugging a crash in your desktop environment on Linux? I am mostly interested as an exercise in actually using the “source” part of open source. Like I imagine it requires:

1. identifying the exact DE version being run

2. fetching the source of that DE version from somewhere and building it in debug configuration

3. running that DE with a debugger attached then triggering the crash

The DE aspect makes it weird, like I would have to run it in a VM maybe so the crash doesn’t take down whatever program I’m using to run the debugger too.

[#]AskFedi #FOSS #Linux

=> More informations about this toot | More toots from ahelwer@discuss.systems

Descendants

Written by hisold on 2025-01-11 at 22:06

@ahelwer I've never done it, but that won't stop me from giving advice. I use KDE and have some idea of how it works.

You can do a lot on your host without a VM.

For example, if the compositor kwin crashes, it can simply be restarted in any open terminal window. Other programs will continue to run and their windows will remain open.

If you have a debugger running, it will continue.

You could probably run the debugger in a different tty.

The KDE wiki has several pages on debugging.

=> More informations about this toot | More toots from hisold@toot.io

Written by Ken Milmore on 2025-01-11 at 22:12

@ahelwer You could start off by enabling core dumps, which can be used for postmortem debugging with gdb. Install the -dbg package for the relevant application and you should get reasonable information from a backtrace. Also don't ignore log files like .xsession-errors. Building specifically for debug tends to be very specific to the application and any libraries which may be involved, so get as much information as you can before trying to build.

=> More informations about this toot | More toots from kbm0@mastodon.social

Written by Greg Parker on 2025-01-11 at 22:41

@ahelwer VMs are great. Trying to fuss with debug builds of your real environment risks putting your installation into a difficult-to-recover state. If you can reproduce the bug in a VM environment your debugging experience will be improved.

On the non-VM side you can go a long way with a command-line debugger in an ssh session from a second computer.

=> More informations about this toot | More toots from gparker@discuss.systems