Bug 437136 - filenamesearch crashes in some root folders
Summary: filenamesearch crashes in some root folders
Status: RESOLVED DUPLICATE of bug 437153
Alias: None
Product: dolphin
Classification: Applications
Component: search (show other bugs)
Version: 21.04.1
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
: 437143 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-05-15 07:46 UTC by Tim
Modified: 2021-05-19 08:58 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
The "journalctl -p 3 -xb > log.log" output (5.62 KB, text/x-log)
2021-05-15 07:46 UTC, Tim
Details
Output of coredumpctrl info /usr/bin/kdeinit5 (5.01 KB, text/plain)
2021-05-15 12:41 UTC, postix
Details
More detailed stacktrace. (6.40 KB, text/vnd.kde.kcrash-report)
2021-05-17 14:08 UTC, postix
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tim 2021-05-15 07:46:52 UTC
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
Comment 1 postix 2021-05-15 12:39:43 UTC
*** Bug 437143 has been marked as a duplicate of this bug. ***
Comment 2 postix 2021-05-15 12:41:22 UTC
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
Comment 3 postix 2021-05-17 14:08:35 UTC
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. :)
Comment 4 Nate Graham 2021-05-18 21:59:45 UTC
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 ***
Comment 5 postix 2021-05-19 08:58:32 UTC
(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!