Created attachment 138444 [details] The "journalctl -p 3 -xb > log.log" output SUMMARY Using Dolphin's search feature in some root folders crashes the filesearch. STEPS TO REPRODUCE 1. Enter "/etc, /sys, /usr, /var, /tmp, /lib, /lib64" or "/run" 2. Open the Filesearch and type anything OBSERVED RESULT Dolphin returns an error message: "The process for the filenamesearch protocol died unexpectedly." EXPECTED RESULT It should actually search for a file in that folder SOFTWARE/OS VERSIONS Linux/KDE Plasma: Garuda Linux (available in About System) KDE Plasma Version: 5.21.5 KDE Frameworks Version: 5.82.0 Qt Version: 5.15.2
*** Bug 437143 has been marked as a duplicate of this bug. ***
Created attachment 138451 [details] Output of coredumpctrl info /usr/bin/kdeinit5 I think I can confirm this issue: I'm unable to search files on a partition via Dolphin (Ctrl+F), which I need to mount it via PolicyKit, since kdeinit5 crashes. Please find the stacktrace attached. Unfortunately, when I have tried to debug it with gdb, gdb itself aborted (core dumped). :-P STEPS TO REPRODUCE 1. Open Dolphin 2. Open a second partition for which it requires root permissions (PolicyKit1-KDE-Agent; org.freedesktop.udisks2.filesystem-mount-system) to mount it within Dolphin 3. Open (Ctrl + F) and conduct a search OBSERVED RESULT - kdeinit5 PID: 3532 Signal: Segmentation fault (11) - process of protocol filenamesearch terminated unexpectedly SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20210512 KDE Plasma Version: 5.21.5 KDE Frameworks Version: 5.82.0 Qt Version: 5.15.2 Kernel Version: 5.12.2-1-default OS Type: 64-bit
Created attachment 138510 [details] More detailed stacktrace. Finally gdb does no longer crash during generating the stacktrace. Thus, please find a more detailed and helpful version attached. :)
Stack trace does not show the crashing thread, but I'm 99% sure this is Bug 437153, which is in the process of being fixed. *** This bug has been marked as a duplicate of bug 437153 ***
(In reply to Nate Graham from comment #4) > Stack trace does not show the crashing thread Why do you think it doesn't show it in attachment 138510 [details]? That's then an issue of Dr. Konqui, not gathering all threads via gdb? However, `thread apply all bt` only shows one additional thread to me: ``` Thread 2 (Thread 0x7f658d05a640 (LWP 4718)): warning: Section `.reg-xstate/4718' in core file too small. #0 0x00007f65913a65cf in __GI___poll (fds=0x7f6588005240, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x00007f658fd6cbce in g_main_context_poll (priority=<optimized out>, n_fds=1, fds=0x7f6588005240, timeout=<optimized out>, context=0x7f6588000c20) at ../glib/gmain.c:4434 #2 g_main_context_iterate (context=context@entry=0x7f6588000c20, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4126 #3 0x00007f658fd6ccef in g_main_context_iteration (context=0x7f6588000c20, may_block=may_block@entry=1) at ../glib/gmain.c:4196 #4 0x00007f65917b0d4b in QEventDispatcherGlib::processEvents (this=0x7f6588000b60, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #5 0x00007f6591757b7b in QEventLoop::exec (this=this@entry=0x7f658d059c90, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69 #6 0x00007f65915753fe in QThread::exec (this=<optimized out>) at ../../include/QtCore/../../src/corelib/global/qflags.h:121 #7 0x00007f658d9c73f7 in QDBusConnectionManager::run (this=0x7f658da40440 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at qdbusconnection.cpp:179 #8 0x00007f6591576541 in QThreadPrivate::start (arg=0x7f658da40440 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at thread/qthread_unix.cpp:329 #9 0x00007f65908d9299 in start_thread (arg=0x7f658d05a640) at pthread_create.c:481 #10 0x00007f65913b14a3 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 ``` Which is probably not the crashing thread -- unlike the posted thread 1, which is basically the same as Kai has posted at #437153. > but I'm 99% sure this is Bug 437153 I agree! > which is in the process of being fixed. Hooray!