https://bugs.kde.org/show_bug.cgi?id=465326
--- Comment #6 from Oded Arbel <o...@geek.co.il> ---
The current behavior (after all today's updates) is that the crash happens
frequently while I'm doing other things, regardless of interaction with the
shell itself, so its hard for me to catch it. But the shell does freeze quite a
lot - at which point plasmashell uses 100% of a core - and if I capture the
backtrace while it happens, the main thread looks like this:
Thread 1 (Thread 0x7f108992f9c0 (LWP 36226) "plasmashell"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x00007f108dccea65 in QtLinuxFutex::_q_futex(int*, int, int, unsigned long
long, int*, int) (val3=0, addr2=0x0, val2=0, val=3, op=0, addr=0x560684982d48)
at thread/qfutex_p.h:114
#2 QtLinuxFutex::futexWait<QBasicAtomicPointer<QMutexData>
>(QBasicAtomicPointer<QMutexData>&, QBasicAtomicPointer<QMutexData>::Type)
(expectedValue=0x3, futex=...) at thread/qfutex_p.h:133
#3 lockInternal_helper<false> (timeout=-1, elapsedTimer=0x0, d_ptr=...) at
thread/qmutex_linux.cpp:142
#4 QBasicMutex::lockInternal() (this=0x560684982d48) at
thread/qmutex_linux.cpp:159
#5 0x00007f108dcced73 in QBasicMutex::lock() (this=0x560684982d48) at
thread/qmutex.h:84
#6 QRecursiveMutexPrivate::lock(int) (this=0x560684982d30,
timeout=timeout@entry=-1) at thread/qmutex.cpp:780
#7 0x00007f108dccec69 in QMutex::lock() (this=this@entry=0x560684983270) at
thread/qmutex.cpp:235
#8 0x00007f10041ef100 in QMutexLocker::QMutexLocker(QBasicMutex*)
(m=0x560684983270, this=<synthetic pointer>) at
/usr/include/x86_64-linux-gnu/qt5/QtCore/qmutex.h:257
#9 QMutexLocker::QMutexLocker(QRecursiveMutex*) (m=0x560684983270,
this=<synthetic pointer>) at
/usr/include/x86_64-linux-gnu/qt5/QtCore/qmutex.h:262
#10 HistoryModel::insert(std::shared_ptr<HistoryItem>) (this=0x560684983250,
item=std::shared_ptr<HistoryItem> (use count 3, weak count 0) = {...}) at
./klipper/historymodel.cpp:135
#11 0x00007f10041ea0d2 in History::insert(std::shared_ptr<HistoryItem>)
(this=<optimized out>, item=std::shared_ptr<HistoryItem> (use count 3, weak
count 0) = {...}) at ./klipper/history.cpp:95
#12 0x00007f10041d4166 in Klipper::applyClipChanges(QMimeData const*)
(this=this@entry=0x5606836c9840, clipData=clipData@entry=0x560688d5a8f0) at
./klipper/klipper.cpp:687
#13 0x00007f10041d6a48 in Klipper::checkClipData(bool) (this=0x5606836c9840,
selectionMode=<optimized out>) at ./klipper/klipper.cpp:828
#14 0x00007f108def40d4 in QtPrivate::QSlotObjectBase::call(QObject*, void**)
(a=0x7ffc7a38d1e0, r=0x5606836c9840, this=0x560684982f70) at
../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398
#15 doActivate<false>(QObject*, int, void**) (sender=0x560684983020,
signal_index=3, argv=0x7ffc7a38d1e0) at kernel/qobject.cpp:3923
#16 0x00007f108d6230a2 in KSystemClipboard::changed(QClipboard::Mode) () at
/lib/x86_64-linux-gnu/libKF5GuiAddons.so.5
#17 0x00007f108def40d4 in QtPrivate::QSlotObjectBase::call(QObject*, void**)
(a=0x7ffc7a38d290, r=0x560684983020, this=0x560684977590) at
../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398
#18 doActivate<false>(QObject*, int, void**) (sender=0x560682375de0,
signal_index=3, argv=0x7ffc7a38d290) at kernel/qobject.cpp:3923
#19 0x00007f108f8a2e2e in ffi_call_unix64 () at ../src/x86/unix64.S:105
#20 0x00007f108f89f493 in ffi_call_int (cif=<optimized out>, fn=<optimized
out>, rvalue=<optimized out>, avalue=<optimized out>, closure=<optimized out>)
at ../src/x86/ffi64.c:672
#21 0x00007f1090451b20 in () at /lib/x86_64-linux-gnu/libwayland-client.so.0
#22 0x00007f10904522c3 in () at /lib/x86_64-linux-gnu/libwayland-client.so.0
#23 0x00007f10904524bc in wl_display_dispatch_queue_pending () at
/lib/x86_64-linux-gnu/libwayland-client.so.0
#24 0x00007f108f92338a in QtWaylandClient::QWaylandDisplay::flushRequests()
(this=<optimized out>) at ./src/client/qwaylanddisplay.cpp:253
#25 0x00007f108dee9ade in QObject::event(QEvent*) (this=0x56068235bb50,
e=0x7f107c013b70) at kernel/qobject.cpp:1347
#26 0x00007f108ed6c793 in QApplicationPrivate::notify_helper(QObject*, QEvent*)
(this=<optimized out>, receiver=0x56068235bb50, e=0x7f107c013b70) at
kernel/qapplication.cpp:3640
#27 0x00007f108debc07a in QCoreApplication::notifyInternal2(QObject*, QEvent*)
(receiver=0x56068235bb50, event=0x7f107c013b70) at
kernel/qcoreapplication.cpp:1064
#28 0x00007f108debf167 in QCoreApplicationPrivate::sendPostedEvents(QObject*,
int, QThreadData*) (receiver=0x0, event_type=0, data=0x560682332ec0) at
kernel/qcoreapplication.cpp:1821
#29 0x00007f108df16487 in postEventSourceDispatch(GSource*, GSourceFunc,
gpointer) (s=0x560682374cc0) at kernel/qeventdispatcher_glib.cpp:277
#30 0x00007f108cb5d569 in g_main_dispatch (context=0x7f1084005010) at
../../../glib/gmain.c:3444
#31 g_main_context_dispatch (context=0x7f1084005010) at
../../../glib/gmain.c:4162
#32 0x00007f108cbb23c8 in g_main_context_iterate.constprop.0
(context=0x7f1084005010, block=<optimized out>, dispatch=1, self=<optimized
out>) at ../../../glib/gmain.c:4238
#33 0x00007f108cb5ad20 in g_main_context_iteration (context=0x7f1084005010,
may_block=1) at ../../../glib/gmain.c:4303
#34 0x00007f108df15ad8 in
QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
(this=0x560682387240, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#35 0x00007f108deba99b in
QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)
(this=this@entry=0x7ffc7a38da50, flags=..., flags@entry=...) at
../../include/QtCore/../../src/corelib/global/qflags.h:69
#36 0x00007f108dec2f34 in QCoreApplication::exec() () at
../../include/QtCore/../../src/corelib/global/qflags.h:121
#37 0x00007f108e3364d0 in QGuiApplication::exec() () at
kernel/qguiapplication.cpp:1870
#38 0x00007f108ed6c709 in QApplication::exec() () at
kernel/qapplication.cpp:2832
#39 0x0000560681cb0a8b in main(int, char**) (argc=<optimized out>,
argv=<optimized out>) at ./shell/main.cpp:235
I also figured out why it takes out my apps - I'm using the systemd service and
I can see that *some* processes launched from the plasma main menu - notably
Eclipse and Chrome - are running in the systemd service's scope instead of
their own app scope, so when the service restarts after the main process
crashes, it kills all the other processes in the scope.
Weirdly, it looks like Plasma does try to run each app in its own scope, but...
for some apps it doesn't work (??)... systemd-cgls shows this weird setup:
─plasma-plasmashell.service (#17260)
├─38246 /usr/bin/plasmashell --no-respawn
├─38282 /lib/x86_64-linux-gnu/libexec/kf5/kioslave5
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/desktop.so desktop
local:/run/user/1000/plasmashelleVuhbK.1.kioworker.socket
├─38374 /lib/x86_64-linux-gnu/libexec/kf5/kioslave5
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/tags.so tags
local:/run/user/1000/plasmashellPtEzPm.2.kioworker.socket
├─38633 /home/odeda/.local/eclipse/eclipse-2022-06-R/eclipse
├─38655
/home/odeda/.local/eclipse/eclipse-2022-06-R//plugins/org.eclipse.justj.openjdk.hotspot.jre.full.linux.x86_64_18.0.1.v20220515-1614/jre/bin/java
--add-opens=java.base/java.io=ALL-UNN>
├─38769 /opt/google/chrome/chrome
...
─app-google\x2dchrome\x2dwork-10fad962c3fb471d93221f0a97b25e63.scope (#17498)
└─38768 /bin/sh -c google-chrome
...
─app-Eclipse-913daf03aafb4e75abc14a51942f13d4.scope (#17461)
└─38632 /bin/sh -c /usr/bin/env GDK_BACKEND=x11
$HOME/.local/eclipse/eclipse-2022-06-R/eclipse
--
You are receiving this mail because:
You are watching all bug changes.
