Plasmashell segfault

Was using my laptop this morning and the screen locked due to inactivity. wentto use my laptop and when i tried to log in, nothing happened. dropped to tty, rebooted, checked journalctl and i can see that plasmashell segfaulted:

Mar 19 06:48:09 thinker systemd-coredump[75706]: Process 1088 (plasmashell) of user 1000 terminated abnormally with signal 11/SEGV, processing…
Mar 19 06:48:09 thinker systemd[870]: plasma-plasmashell.service: Main process exited, code=dumped, status=11/SEGV
Mar 19 06:48:09 thinker systemd[870]: plasma-plasmashell.service: Failed with result ‘core-dump’.
Mar 19 06:48:09 thinker systemd[870]: plasma-plasmashell.service: Consumed 36min 17.857s CPU time, 927.7M memory peak.
Mar 19 06:48:50 thinker plasmashell[1066]: QThreadStorage: Thread 0x60c711d62540 exited after QThreadStorage 8 destroyed
Mar 19 06:48:50 thinker plasmashell[1066]: QThreadStorage: Thread 0x60c711d62540 exited after QThreadStorage 3 destroyed
Mar 19 06:48:50 thinker plasmashell[1066]: QThreadStorage: Thread 0x60c711d62540 exited after QThreadStorage 2 destroyed

updated my system in hopes this would fix it, was running plasma 6.3.2 on linux 6.13.6-arch1-1 when this happened. also don’t know if this is relevant, but my trackpoint’s mouse buttons sometimes stop working when waking from sleep, going to sleep and waking back up fixes this.

Hi - for what it’s worth, other than making sure you’re up-to-date with Plasma version 6.3.3, it might be worthwhile to double-check your hardware for issues (like memory errors) if you’re suddenly getting multiple, seemingly unrelated software and hardware bugs cropping up.

If the crash that you experienced is reproducible, then the Community Wiki guide here has helpful steps on how to create a useful report for KDE developers to be able to investigate: Guidelines and HOWTOs/Debugging/How to create useful crash reports - KDE Community Wiki

it happened again, i dont see an obvious error. please help

Mar 19 06:48:09 thinker systemd-coredump[75706]: Process 1088 (plasmashell) of user 1000 terminated abnormally with signal 11/SEGV, processing…
Mar 19 06:48:09 thinker systemd[870]: plasma-plasmashell.service: Main process exited, code=dumped, status=11/SEGV
Mar 22 11:54:47 thinker systemd-coredump[245809]: Process 1084 (plasmashell) of user 1000 terminated abnormally with signal 11/SEGV, processing…
Mar 22 11:54:47 thinker systemd[869]: plasma-plasmashell.service: Main process exited, code=dumped, status=11/SEGV

its the same as before

[SOVLED]log into the KDE desktop(wayland), plasmashell... crashes / Applications & Desktop Environments / Arch Linux Forums found this and it seems relevant, is there some way i can fix this?

Sounds like that’s the most relevant thread that’s ongoing - if the way that’s happening is just impacting Arch users, then it might be an issue with how Arch has packaged the kernel/Qt/something else fundamental to the system? Others may have better ideas here.

Other than keeping up with your distro’s updates, I’d just recommend making sure that crashes are reported when they occur, so developers can be aware: Guidelines and HOWTOs/Debugging/How to create useful crash reports - KDE Community Wiki

this looks really complicated, is there an easy way to get the relevant info and send this to someone? how would i even find the backtrace, if one was even created? not to mention i don’t even know how to read these

yeah, nothing in my journal about a backtrace

That page that I linked to is the guide to getting the relevant info - you’d need to install debugging packages for Arch Linux, then use either the KDE Crash Report Tool or coredumpctl to create a backtrace (it wouldn’t automatically appear in your system journal).

i’m just not sure how i would intentionally crash my desktop environment to make a backtrace or if i even want to do that unless i’m misunderstanding. this is an intermittent issue.

also scared i’ll mess something up and break my computer somehow

The coredumpctl section of that page starts with:

If your application crashed in the past and you cannot get it to crash again, it is often possible to retrieve the backtrace anyway using the coredumpctl tool.

So that’s the approach you’d take there.

Keep on going for it if you’re enjoying the challenge - I don’t mean to discourage you - but Arch Linux might not be the distribution that’s best suited for your primary working device at this time?

From Frequently asked questions - ArchWiki :

You may not want to use Arch, if:

  • you do not have the ability/time/desire for a ‘do-it-yourself’ GNU/Linux distribution.

i’m quite comfortable with arch, i’ve found it to be pretty stable and i’m able to customise it to do what i want. i’ve used it for about 5 years now without any major issues. i just get a bit spooked when trying to do anything super out of the ordinary, like in this case.

ran coredumpctl and the only core dump listed is for schildichat which is when i ran out of RAM and is unrelated to what kde was doing.