https://bugs.kde.org/show_bug.cgi?id=523180
Bug ID: 523180
Summary: Plasmashell goes into crash loop when resuming from
standby
Classification: Plasma
Product: plasmashell
Version First 6.6.5
Reported In:
Platform: Slackware
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: 1.0
Created attachment 194377
--> https://bugs.kde.org/attachment.cgi?id=194377&action=edit
01-gdb-backtrace
DESCRIPTION
There seems to be a bug, similar symptoms but probably different cause to bug
https://bugs.kde.org/show_bug.cgi?id=501086
Plasmashell goes into a crash loop sometimes when I turn on my laptop again
after being in standby.
STEPS TO REPRODUCE
1. Use my laptop for a while
2. put laptop in standby
3. resume from standby and type password in
4. plasmashell appears for a bit and then crashes, and does that for several
times until it gives up.
SIGSEGV
I thought it might have been the Fokus plasmoid but removing that has made no
change to this issue
SOFTWARE/OS VERSIONS
Operating System (available in the Info Center app, or by running `kinfo` in a
terminal window):
Operating System: NixOS 26.05
KDE Plasma Version: 6.6.5
KDE Frameworks Version: 6.26.0
Qt Version: 6.11.1
Kernel Version: 6.18.37 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7840U w/ Radeon 780M Graphics
Memory: 64 GiB of RAM (60,6 GiB usable)
Graphics Processor: AMD Radeon 780M Graphics
Manufacturer: Framework
Product Name: Laptop 13 (AMD Ryzen 7040Series)
System Version: A7
ADDITIONAL INFORMATION
DISCLAIMER: EVERYTHING AFTER THIS IS CREATED BY AN LLM FOR WHAT IT THINKS MIGHT
BE THE CAUSE
so .... take it with a bucket of salt.
## Trigger
Crash happens on resume from suspend (lid open). It does not happen on
a fresh boot. Reproduced multiple times across reboots.
## Crash signature
The crash is a null pointer dereference inside Qt's text layout code,
triggered while painting a QLabel:
```
#7 QTextDocument::d_func (this=0x0) ← null this
at qtextdocument.h:297
#8 QTextDocumentPrivate::get (document=0x0) ← null document
at qtextdocument_p.h:275
#9 QTextDocumentPrivate::get (object=0x...)
at qtextdocument_p.h:295
#10 QTextFrame::begin (this=0x...)
at qtextobject.cpp:589
#11 QTextDocumentLayoutPrivate::layoutFrame(...)
at qtextdocumentlayout.cpp:3028
#12 QTextDocumentLayoutPrivate::layoutFrame(...)
at qtextdocumentlayout.cpp:2919
#13 QTextDocumentLayout::doLayout(...)
at qtextdocumentlayout.cpp:3838
#14 QTextDocumentLayout::documentChanged(...)
at qtextdocumentlayout.cpp:3801
#15 QTextDocumentPrivate::clear(...)
at qtextdocument_p.cpp:251
#16 QTextDocument::setPlainText(...)
at qtextdocument.cpp:1271
#17 QLabelPrivate::ensureTextPopulated(...)
at qlabel.cpp:1507
#22 QLabel::paintEvent(...)
at qlabel.cpp:1006
```
The paint is triggered by a Wayland expose event on resume:
```
#46 QWindowSystemInterface::handleExposeEvent(...)
#47 QtWaylandClient::QWaylandWindow::sendExposeEvent(...)
#48 QtWaylandClient::QWaylandWindow::updateExposure()
```
Immediately before the crash, the journal shows a thread-safety
violation in the Breeze widget style engine:
```
plasmashell: QObject: Cannot create children for a parent that is in a
different thread.
(Parent is Breeze::WidgetStateEngine(...), parent's thread is QThread(...),
current thread is QThread(0x...))
```
This matches the signature of KDE bug 465454 ("plasmashell crashes in
QTextDocument::docHandle"), originally fixed in plasma-workspace 5.27
by commit 402ebdbde ("dataengines/mpris2: don't recreate PlayerControl
for the same container"). The KDE 6 codebase removed/rewrote the
dataengines/mpris2 code (now in libkmpris/Multiplexer), so the fix no
longer applies, and the same class of thread-safety bug appears to have
been reintroduced.
## Files in attachment
- `01-gdb-backtrace.txt` — main thread backtrace from `coredumpctl gdb`
with debug symbols resolved (source file/line numbers). This is the
key file.
- `02-gdb-full-backtrace-all-threads.txt` — full `thread apply all bt`
output. Includes all ~80 threads (most are idle worker threads).
- `03-coredumpctl-info.txt` — `coredumpctl info` output: signal, PID,
command line, coredump metadata.
- `04-journal-user-crash-window.txt` — user journal for ~5 min before
and after the crash. Shows the resume event, the Breeze thread
warnings, and the KCrash handler invocation.
- `05-journal-system-crash-window.txt` — system journal for the same
window. Shows the suspend/resume cycle and amdgpu resume.
--
You are receiving this mail because:
You are watching all bug changes.
