Frequent org_kde_powerde crashes causing trouble

Hi everybody.
Having some trouble and hoping the community can offer some insight. Files have been appearing in ~/ for months with impossible file names not recognized by Dolphin or other programs. Initially, I was ignoring them but lately they have become a major nuisance since they disrupt working in ~/ in an application I have started using. Below is an example of two of these files which appeared recently:


Opening one up, below are the contents. Contents of the other file are similar.


sudo journalctl --no-pager -p 3 -xb returned:

May 17 16:44:02 mycomputername systemd-coredump[602067]: [🡕] Process 600452 (org_kde_powerde) of user 1000 dumped core.
                                                   Module from deb systemd-252.22-1~deb12u1.amd64
                                                   Module from deb systemd-252.22-1~deb12u1.amd64
                                                   Stack trace of thread 600452:
                                                   #0  0x00007fe9f24aed14 pthread_sigmask ( + 0x8fd14)
                                                   #1  0x00007fe9f245b239 sigprocmask ( + 0x3c239)
                                                   #2  0x00007fe9f36e9e9b _ZN6KCrash15setCrashHandlerEPFviE ( + 0x4e9b)
                                                   #3  0x00007fe9f36eab3e _ZN6KCrash19defaultCrashHandlerEi ( + 0x5b3e)
                                                   #4  0x00007fe9f245b050 n/a ( + 0x3c050)
                                                   #5  0x00007fe9e8fd18c6 n/a ( + 0x148c6)
                                                   #6  0x00007fe9ed60cf7a n/a ( + 0x6f7a)
                                                   #7  0x00007fe9ed60c40e n/a ( + 0x640e)
                                                   #8  0x00007fe9ed60cb0d ffi_call ( + 0x6b0d)
                                                   #9  0x00007fe9ecfe6761 n/a ( + 0xa761)
                                                   #10 0x00007fe9ecfe2aaa n/a ( + 0x6aaa)
                                                   #11 0x00007fe9ecfe441c wl_display_dispatch_queue_pending ( + 0x841c)
                                                   #12 0x00007fe9ecb2b872 _ZN15QtWaylandClient15QWaylandDisplay13flushRequestsEv ( + 0x76872)
                                                   #13 0x00007fe9f28dd6f0 _ZN7QObject5eventEP6QEvent ( + 0x2dd6f0)
                                                   #14 0x00007fe9f28b16f8 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent ( + 0x2b16f8)
                                                   #15 0x00007fe9f28b4681 _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData ( + 0x2b4681)
                                                   #16 0x00007fe9f290a153 n/a ( + 0x30a153)
                                                   #17 0x00007fe9f151e7a9 g_main_context_dispatch ( + 0x547a9)
                                                   #18 0x00007fe9f151ea38 n/a ( + 0x54a38)
                                                   #19 0x00007fe9f151eacc g_main_context_iteration ( + 0x54acc)
                                                   #20 0x00007fe9f2909836 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE ( + 0x309836)
                                                   #21 0x00007fe9f28b017b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE ( + 0x2b017b)
                                                   #22 0x00007fe9f28b82d6 _ZN16QCoreApplication4execEv ( + 0x2b82d6)
                                                   #23 0x0000559c635d1c6e n/a (org_kde_powerdevil + 0x6c6e)
                                                   #24 0x00007fe9f244624a n/a ( + 0x2724a)
                                                   #25 0x00007fe9f2446305 __libc_start_main ( + 0x27305)
                                                   #26 0x0000559c635d1cd1 n/a (org_kde_powerdevil + 0x6cd1)
                                                   Stack trace of thread 600457:
                                                   #0  0x00007fe9f251b15f __poll ( + 0xfc15f)
                                                   #1  0x00007fe9f151e9ae n/a ( + 0x549ae)
                                                   #2  0x00007fe9f151eacc g_main_context_iteration ( + 0x54acc)
                                                   #3  0x00007fe9f290984e _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE ( + 0x30984e)
                                                   #4  0x00007fe9f28b017b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE ( + 0x2b017b)
                                                   #5  0x00007fe9f26cab87 _ZN7QThread4execEv ( + 0xcab87)
                                                   #6  0x00007fe9f3435487 n/a ( + 0x17487)
                                                   #7  0x00007fe9f26cbd43 n/a ( + 0xcbd43)
                                                   #8  0x00007fe9f24a8134 n/a ( + 0x89134)
                                                   #9  0x00007fe9f25287dc n/a ( + 0x1097dc)
                                                   Stack trace of thread 600456:
                                                   #0  0x00007fe9f251b15f __poll ( + 0xfc15f)
                                                   #1  0x00007fe9ecb2fcd6 n/a ( + 0x7acd6)
                                                   #2  0x00007fe9f26cbd43 n/a ( + 0xcbd43)
                                                   #3  0x00007fe9f24a8134 n/a ( + 0x89134)
                                                   #4  0x00007fe9f25287dc n/a ( + 0x1097dc)
                                                   Stack trace of thread 600455:
                                                   #0  0x00007fe9f24a4e96 n/a ( + 0x85e96)
                                                   #1  0x00007fe9f24a7558 pthread_cond_wait ( + 0x88558)
                                                   #2  0x00007fe9f26d1a2b _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer ( + 0xd1a2b)
                                                   #3  0x00007fe9ecb2fc7f n/a ( + 0x7ac7f)
                                                   #4  0x00007fe9f26cbd43 n/a ( + 0xcbd43)
                                                   #5  0x00007fe9f24a8134 n/a ( + 0x89134)
                                                   #6  0x00007fe9f25287dc n/a ( + 0x1097dc)
                                                   Stack trace of thread 600496:
                                                   #0  0x00007fe9f251da41 pselect ( + 0xfea41)
                                                   #1  0x00007fe9f12b6a62 n/a ( + 0x2a62)
                                                   #2  0x00007fe9f12b7e60 n/a ( + 0x3e60)
                                                   #3  0x00007fe9f24a8134 n/a ( + 0x89134)
                                                   #4  0x00007fe9f25287dc n/a ( + 0x1097dc)
                                                   Stack trace of thread 600458:
                                                   #0  0x00007fe9f251b15f __poll ( + 0xfc15f)
                                                   #1  0x00007fe9f151e9ae n/a ( + 0x549ae)
                                                   #2  0x00007fe9f151eacc g_main_context_iteration ( + 0x54acc)
                                                   #3  0x00007fe9f151eb11 n/a ( + 0x54b11)
                                                   #4  0x00007fe9f1548cfd n/a ( + 0x7ecfd)
                                                   #5  0x00007fe9f24a8134 n/a ( + 0x89134)
                                                   #6  0x00007fe9f25287dc n/a ( + 0x1097dc)
                                                   Stack trace of thread 600459:
                                                   #0  0x00007fe9f251b15f __poll ( + 0xfc15f)
                                                   #1  0x00007fe9f151e9ae n/a ( + 0x549ae)
                                                   #2  0x00007fe9f151ecef g_main_loop_run ( + 0x54cef)
                                                   #3  0x00007fe9eb1cd7b6 n/a ( + 0x1197b6)
                                                   #4  0x00007fe9f1548cfd n/a ( + 0x7ecfd)
                                                   #5  0x00007fe9f24a8134 n/a ( + 0x89134)
                                                   #6  0x00007fe9f25287dc n/a ( + 0x1097dc)
                                                   ELF object binary architecture: AMD x86-64
░░ Subject: Process 600452 (org_kde_powerde) dumped core
░░ Defined-By: systemd
░░ Support:
░░ Documentation: man:core(5)
░░ Process 600452 (org_kde_powerde) crashed and dumped core.
░░ This usually indicates a programming error in the crashing program and
░░ should be reported to its vendor as a bug.

These are almost certainly related due to the log timestamp matching the time of the file creation in ~/. So, I believe I have identified the cause, but I am quite new to Linux/Debian/KDE and do not really know what to do to investigate the issue further and find a solution. Would really appreciate any assistance and advice to try to fix this. Thank you very much in advance.

Hi all - any feedback on this question? Happy to attempt anything. Thanks.

org_kde_powerde is shortened from org_kde_powerdevil, which is Plasma’s power management service. However, your stack trace has literally no information about what PowerDevil is actually trying to do at the time, the only thing we see is that there’s some event that causes the underlying Qt library to try to interact with the Wayland server. And crashes in the process.

The important parts, that is, the debug symbols and source lines right below the crash handler, are missing in your stack trace. One thing you could try is to get a better stack trace that includes more of this debug information, probably by finding the relevant crash through the coredumpctl CLI before it expires - use the dump subcommand to export the better dump after first listing the crashes with coredumpctl list.

Having crashed with signal 6 probably means there’s some kind of bad memory access involved. That’s an incredibly vast scope though and it’s hard to tell without digging deeper.

Given that we’re talking about a background service, Wayland is something that most of the program isn’t using. If I had to make a very broad guess, I’d say it could be something related to user (in)activity monitoring and/or automatically turning off the screen after a given amount of time. Those are the things I know PowerDevil uses Wayland for, it asks the KWin compositor for help with that when using Wayland.

Based on that, and the fact that Plasma 5.27 probably won’t get significant bug fixes anymore (6.0 is the current stable release, with 6.1 almost here), I would suggest to try two things.

  1. In System Settings, Energy Saving settings module, disable the “Turn off screen” functionality and see if this fixes or reduces such core dumps being produced.
  2. Switch to X11 until you can upgrade to a newer Plasma version that hopefully does not have this issue anymore.

A quick internet search indicates that the systemd-252.22-1~deb12u1 package is coming from Debian. While spending a lot of time on “stabilization”, Debian is also known to ship old software when it finally releases. Debian 12, which released last June, only ships Plasma 5.27.5 as opposed to 5.27.11, missing out on six additional bugfix releases that may have already fixed your crash. And that’s ignoring all the work that went into Plasma 6 since then.

If you can’t find a good solution on your current system, consider switching to a distribution that at least commits to packaging stable bugfix releases for the supported period of your major desktop release. Such as Kubuntu, Tuxedo OS, or (higher up on the cutting edge scale) Fedora KDE Spin. As a desktop user, this can pay off. And as developers, we’d like to get more people using software that incorporates at least most of the fixes that have already been released to the public.

1 Like

Hi jpetso, and first of all thank you very much for your detailed reply. I will try to address everything you mentioned.
So, first of all, I found thousands and thousands of entries in coredumpctl list from /usr/lib/x86_64-linux-gnu/libexec/org_kde_powerdevil. It seems there is a new entry every 10 minutes and 3 seconds like clockwork. Here is a recent dump, hopefully this is what you’re looking for:

           PID: 4091314 (org_kde_powerde)
           UID: 1000 (myusername)
           GID: 1000 (myusername)
        Signal: 11 (SEGV)
     Timestamp: Tue 2024-05-28 17:09:32 CDT (2h 42min ago)
  Command Line: /usr/lib/x86_64-linux-gnu/libexec/org_kde_powerdevil
    Executable: /usr/lib/x86_64-linux-gnu/libexec/org_kde_powerdevil
 Control Group: /user.slice/user-1000.slice/user@1000.service/background.slice/plasma-powerdevil.service
          Unit: user@1000.service
     User Unit: plasma-powerdevil.service
         Slice: user-1000.slice
     Owner UID: 1000 (myusername)
       Boot ID: 
    Machine ID: 
       Storage: /var/lib/systemd/coredump/core.org_kde_powerde.1000.c8d6d6e3d3d441eea6f080cd2f35fc82.4091314.1716934172000000.zst (present)
  Size on Disk: 1.0M
       Message: Process 4091314 (org_kde_powerde) of user 1000 dumped core.
                Module from deb systemd-252.22-1~deb12u1.amd64
                Module from deb systemd-252.22-1~deb12u1.amd64
                Stack trace of thread 4091314:
                #0  0x00007f02848aed14 pthread_sigmask ( + 0x8fd14)
                #1  0x00007f028485b239 sigprocmask ( + 0x3c239)
                #2  0x00007f0285960e9b _ZN6KCrash15setCrashHandlerEPFviE ( + 0x4e9b)
                #3  0x00007f0285961b3e _ZN6KCrash19defaultCrashHandlerEi ( + 0x5b3e)
                #4  0x00007f028485b050 n/a ( + 0x3c050)
                #5  0x00007f0284ce8ceb n/a ( + 0x2e8ceb)
                #6  0x00007f0267236e32 n/a ( + 0x8e32)
                #7  0x00007f0267240843 n/a ( + 0x12843)
                #8  0x00007f027f829f7a n/a ( + 0x6f7a)
                #9  0x00007f027f82940e n/a ( + 0x640e)
                #10 0x00007f027f829b0d ffi_call ( + 0x6b0d)
                #11 0x00007f027f839761 n/a ( + 0xa761)
                #12 0x00007f027f835aaa n/a ( + 0x6aaa)
                #13 0x00007f027f83741c wl_display_dispatch_queue_pending ( + 0x841c)
                #14 0x00007f027f160872 _ZN15QtWaylandClient15QWaylandDisplay13flushRequestsEv ( + 0x76872)
                #15 0x00007f0284cdd6f0 _ZN7QObject5eventEP6QEvent ( + 0x2dd6f0)
                #16 0x00007f0284cb16f8 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent ( + 0x2b16f8)
                #17 0x00007f0284cb4681 _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData ( + 0x2b4681)
                #18 0x00007f0284d0a153 n/a ( + 0x30a153)
                #19 0x00007f02837d47a9 g_main_context_dispatch ( + 0x547a9)
                #20 0x00007f02837d4a38 n/a ( + 0x54a38)
                #21 0x00007f02837d4acc g_main_context_iteration ( + 0x54acc)
                #22 0x00007f0284d09836 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE ( + 0x309836)
                #23 0x00007f0284cb017b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE ( + 0x2b017b)
                #24 0x00007f0284cb82d6 _ZN16QCoreApplication4execEv ( + 0x2b82d6)
                #25 0x00005574d5f94c6e n/a (org_kde_powerdevil + 0x6c6e)
                #26 0x00007f028484624a n/a ( + 0x2724a)
                #27 0x00007f0284846305 __libc_start_main ( + 0x27305)
                #28 0x00005574d5f94cd1 n/a (org_kde_powerdevil + 0x6cd1)
                Stack trace of thread 4091321:
                #0  0x00007f02838292b0 g_mutex_unlock ( + 0xa92b0)
                #1  0x00007f02837d3ed0 g_main_context_prepare ( + 0x53ed0)
                #2  0x00007f02837d48e3 n/a ( + 0x548e3)
                #3  0x00007f02837d4acc g_main_context_iteration ( + 0x54acc)
                #4  0x00007f0284d0984e _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE ( + 0x30984e)
                #5  0x00007f0284cb017b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE ( + 0x2b017b)
                #6  0x00007f0284acab87 _ZN7QThread4execEv ( + 0xcab87)
                #7  0x00007f0284f86487 n/a ( + 0x17487)
                #8  0x00007f0284acbd43 n/a ( + 0xcbd43)
                #9  0x00007f02848a8134 n/a ( + 0x89134)
                #10 0x00007f02849287dc n/a ( + 0x1097dc)
                Stack trace of thread 4091320:
                #0  0x00007f028491b15f __poll ( + 0xfc15f)

In Energy Saving settings, I disabled the “Screen Energy Saving” function, which looks to be the closest to the “Turn off screen” functionality you mentioned. Let’s see if this helps at all.

Regarding distribution, you are correct that the machine is running Debian. Debian was recommended to me for setting up my server, though I am quite sure your criticism and remarks are fully valid. I could consider another distribution but this would be a last resort approach. Is there no way to update to Plasma 5.27.11 or even 6? Or perhaps this is not recommended.

Please let me know your thoughts and if there is anything else I can try.

1 Like

The stack trace isn’t substantially different to the previous one where it matters, also failing somewhere in without further symbols. Not sure if dump doesn’t download the extra info through debuginfod, or if one needs coredumpctl debug with bt command for that to work.

Either way, the 10 min, 3 sec interval is definitely interesting. Especially combined with “10 min” switch-off period. I’m very curious about your next report, if it stops crashing then I guess this should be noticeable soon enough.

Is there no way to update to Plasma 5.27.11 or even 6? [on Debian]

I wouldn’t say I’m an expert on KDE on Debian, but this Reddit comment seems insightful as a helpful summary. If I used the Debian Backports website correctly, it seems like there are no backports at least for the powerdevil package. For another recent forum thread focusing on Plasma 6, you can have a look at some more opinions:

One thing you could consider is to switch from Debian stable to Debian testing, which is more current but still known as relatively stable in general. Although as an actual rolling release it has some different characteristics, which make it less ideal for a server system.

It really depends on what you’re looking for, I don’t want to advocate for a cumbersome switch if you’re otherwise happy with the way that Debian stable handles things. As long as you’re aware that throughout much of the time during a stable release’s lifetime, the software is somewhere between outdated and already unsupported, with all the trade-offs that this brings.

1 Like

Thanks again for all the insight. It has only been a day since disabling the Screen Energy Saving setting so it is too early to say with any kind of certainty, but I wanted to give an update since you have been so helpful and responsive. So far no new problematic files have been generated in ~/. Additionally, I see no more of the 10 min 3 sec crashes in coredumpctl, which is a definite improvement. I will report back if anything changes, but I am optimistic at the moment. Thank you again.