This guide serves as a collection of useful resources for debugging plasmashell. As plasmashell controls essentially all widgets on your desktop, a faulty widget might be hard to spot at first sight. Likewise, any official widget issues should be reported to bugs.kde.org under the plasmashell product.
Check widgets dynamically
This procedure is useful for checking for memory leaks.
- Open Konsole and press Meta+Right to tile it to the right.
journalctl /usr/bin/plasmashelland check whether any warnings or errors are present.
- If there are, run
journalctl /usr/bin/plasmashell -f 2> plasmashell.logto check logs in real time and paste it automatically into a log.
- Open the default process manager based on KSysGuard by pressing Ctrl+Esc, then press Meta+Left to tile it to the left. Write
plasmashellto filter it for easier visualization, or just select it. Take note of memory usage.
- Click each individual widget on the panel and check if any warnings appear on Konsole as well as whether there is any change in memory usage on the process manager. If after closing a widget memory usage comes back to normal, it's fine. If this does not occur, this might indicate a memory leak, so check if it occurs repeatedly.
- You should now have a file named plasmashell.log on your home folder that you may send to the devs together with your bug report over bugs.kde.org.
Simply opening a widget may not cause an increase in memory. If you want to verify this more thoroughly, click each individual action in that widget, or check each widget individually as shown in the next section.
You may also want to use this after you've determined a way to reproduce a crash in plasmashell caused by a widget. If so, run some debug tool such as gdb, valgrind, or strace.
Check widgets individually
- Open Konsole
- If the widget you want to check is system-wide, list all available system widgets with
ls /usr/share/plasma/plasmoids/, then locate the widget you want to check.
- If the widget you want to check was installed by you/is made by a third-party, list all available user widgets with
ls .local/share/plasma/plasmoids/, then locate the widget you want to check. Remember that if an issue is found with a third-party widget, it should be reported to the original developer, not to the KDE developers.
- You can use plasmawindowed (available by default on Plasma) or plasmoidviewer (made available in plasma-sdk) to run a widget individually. plasmawindowed runs the widget separately but as if running natively, plasmoidviewer is more developer-oriented and allows you to set positions and whatnot. For general debugging, plasmawindowed should suffice.
- Run a debug tool such as gdb like so:
If any debug symbols are missing, GDB will tell you. Depending on your package manager it might even tell you what command to run in order to fetch the required debug symbols, in which case you should install such packages before continuing. Follow the instructions provided by your distribution for that.
- Inside gdb, execute the command
set logging onbefore anything else so a file named gdb.txt is created. Optionally, you may want to
set logging file filename.txtbefore it to have a special filename for your log.
- Then execute
run org.kde.plasma.plasmoidname, utilizing the correct widget name you saw in the plasma/plasmoids folder. The widget should now run standalone with a few window controls (minimize, maximize, close) on top.
The run command inside gdb executes the application, and anything coming after run should be its arguments or options. Thus, it works analogously to
plasmawindowed org.kde.plasma.plasmoidname, except GDB will log everything or most things you need.
- Test as much as you want, then close the widget by clicking the close button.
- Back to gdb, run
thread apply all backtraceto create the backtrace.
Typically your usual backtrace would be created by running
bt, but by default it is limited to a single thread. DrKonqi, the default crash handler, retrieves the information of all threads available in order to provide context for the developer, and we use
thread apply all backtrace here for the same reason.
- Finish by running
- You should now have a file named gdb.txt on your home folder that you may send to the devs together with your bug report over bugs.kde.org.
Attach gdb to the plasmashell process
It is possible to attach GDB to a running process, in this case plasmashell. With this, you should have a crash log and backtrace even if your system completely freezes somehow.
To do this, GDB will need to know the PID of the plasmashell process. It is possible to do so manually with
ps -aux | grep plasmashell, say, 2000, and then running
gdb plasmashell 2000, or perhaps
gdb -p 2000, but for efficiency you may just
gdb -p $(pidof plasmashell) (This will fetch the PID of plasmashell for you automatically and it should run fine in bash, sh, ksh and zsh, in fish you'd use
gdb -p (pidof plasmashell) instead).
After that, it's mostly the same process described above. When GDB is attached to an application, the application is "stopped" temporarily while GDB waits for input. Run
set logging file plasmashell.txt, then
set logging on, then run
continue; this should make plasmashell continue running as usual. Wait for the crash to happen, then return to gdb and type
thread apply all backtrace to generate a backtrace. Lastly, run
quit to exit gdb.
Automate generation of backtraces with batch
GDB provides an easy way to automate debugging: the
-batch flag. After enabling it, you should be able to run commands sequentially with
--eval-command. If you don't want to see any output on your terminal, you might want to use
-batch-silent instead. Let's see three examples of this:
- Run application and provide general backtrace:
gdb plasmashell -batch -ex "set logging file plasmashell.txt" -ex "set logging on" -ex "run" -ex "thread apply all backtrace" -ex "quit"
(Note that in the case of running plasmashell from the start, you need to kill it first.)
- Attach to application and provide general backtrace:
gdb -pid $(pidof plasmashell) -batch -ex "set logging file plasmashell.txt" -ex "set logging on" -ex "continue" -ex "thread apply all backtrace" -ex "quit"
- Attach to application and be extra quiet:
gdb --silent -pid $(pidof plasmashell) -batch-silent -ex "set logging file plasmashell.txt" -ex "set logging on" -ex "continue" -ex "thread apply all backtrace" -ex "quit"
Full log of memory leaks with Valgrind
After checking which widgets are causing the issue, you can verify what piece of code is causing a memory leak. Where GDB excels for creating backtraces, Valgrind is most known for its use in detecting memory leaks. Unfortunately, Valgrind lacks the ability to attach to running processes, but this should be no issue for Plasmashell.
First, terminate the current Plasmashell session with
Then simply initiate a Plasmashell process via Valgrind:
valgrind --leak-check=full --show-reachable=yes --track-origins=yes --trace-children=yes --log-file=plasmashell.log plasmashell
Alternatively, as mentioned above in section Check widgets individually, you can initiate a plasmawindowed process containing the faulty widget via Valgrind:
valgrind --leak-check=full --show-reachable=yes --track-origins=yes --trace-children=yes --log-file=plasmoidname.log plasmawindowed org.kde.plasma.plasmoidname
If any additional info is required, the developers will mention how to acquire the desired information.