Bug 433611

I am also encountering this issue on Plasma Version 6.2.4, Dolphin Version 24.12.0, and KDE Frameworks Version 6.9.0.
In my case, the bug appears when accessing a CIFS network share mounted via /etc/fstab. 
The share is accessed over a slow VPN connection, which causes Dolphins UI to hang. 
The problem does not occur when the same share is mounted directly within Dolphin (without adding it to /etc/fstab).

(In reply to Jens from comment #0)

This is likely the same as bug 494224. We need a backtrace in order to find out for sure.

Can you please attach a backtrace of the crash using the `coredumpctl` command-line program, as detailed in [https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl](https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl)?

Thanks!


(In reply to Jens from comment #1)
Different crashes might have different causes, even if the symptoms look similar. You'll also need to get us a backtrace and we can see.

Thanks again!

Created attachment 178140 [details]
Trace with gdb

Created attachment 178141 [details]
Trace with valgrind

(In reply to TraceyC from comment #2)
> (In reply to Jens from comment #0)
> 
> This is likely the same as bug 494224. We need a backtrace in order to find
> out for sure.
> 
> Can you please attach a backtrace of the crash using the `coredumpctl`
> command-line program, as detailed in
> [https://community.kde.org/Guidelines_and_HOWTOs/Debugging/
> How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl](
> https://community.kde.org/Guidelines_and_HOWTOs/Debugging/
> How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl)?
> 
> Thanks!
> 
> 
> (In reply to Jens from comment #1)
> Different crashes might have different causes, even if the symptoms look
> similar. You'll also need to get us a backtrace and we can see.
> 
> Thanks again!

I've collected traces using both valgrind and gdb as described in the Guidelines and Attached them. 
To clarify, I did not observe an actual crash, but rather Dolphin becomes completely unresponsive. 
Here’s what I did in the traces:

  1. I launched Dolphin and connected to the VPN.
  2. I mounted the network shares defined in /etc/fstab.
  3. I navigated to the network share folders, then to a local folder.
  4. I disconnected the VPN connection, and Dolphin then froze while trying to navigate to another local folder.
  5. I waited a few minutes
  6. I killed dolphin 

Once the VPN was reconnected, Dolphin became responsive again almost immediately.
So, the program does not crash, but freezes completely while trying to interact with local directories after the VPN disconnects. 
I hope this helps, and feel free to let me know if you need anything else.

Thanks for the backtraces. I'll let one of the more experienced contributors take it from here.

I'm also experiencing this issue, both with SMB and with NFS shares with Dolphin 25.04.3 (on KDE Plasma 6.3.6)

Any news about this hug?
Dolphin constantly freezing is driving me insane... 😑
Thank you!

I understand this is a frustrating issue. Please be patient. Many KDE developers are volunteers, working in their spare time. There are literally thousands of opened bugs. This will be addressed when someone with the appropriate knowledge has the time.

In the meantime, the workaround is to set "noauto" on the mounts in /etc/fstab that cause Dolphin to freeze, so it isn't auto mounted (so it can't cause issues if the share isn't available). Also, you can use xkill to force close the Dolphin window.

Thanks for the heads up. I'm aware this is all volunteer work, no offense intended.

I have now worked around it by force umounting all network shares when suspending, and before shutdown, to avoid these hangs.
If I can help to find a real solution here in any other way, please do ask!

(In reply to daniel_moelders from comment #3)
> Created attachment 178140 [details]
> Trace with gdb

#0  __GI___fstatat64 (fd=-100, file=0x5555562120f0 "/mnt/truenas/service_data", buf=0x7fffffffc1e0, flag=256) at ../sysdeps/unix/sysv/linux/fstatat64.c:159
        r = -512
#1  0x00007ffff7940b43 in KMountPoint::possibleMountPoints (infoNeeded=..., infoNeeded@entry=...) at /usr/src/debug/kio/kio-6.10.0/src/core/kmountpoint.cpp:194

We don't have a way from the system perspective to know in advance whether a filesystem is "working" i.e accessible or not beforehand.
Or at least I don't know how to do that.

A potential complicated solution is to use libiouring since it allows to do asynchrouns syscalls and cancel them.
statvfs is not one handled.

https://bugs.kde.org/show_bug.cgi?id=423187
https://bugs.kde.org/show_bug.cgi?id=441077
https://bugs.kde.org/show_bug.cgi?id=445065
https://bugs.kde.org/show_bug.cgi?id=503995

If there is no way to safely (ie. without stall or crash) handle remote file systems, I would suggest to not touch them at all unless the user explicitly asks to (ie. clicks on a mountpoint). Don't enumerate or walk through all mounted devices if this may cause having to wait for a timeout.

Alternatively, how complicated is the async solution? Is it feasible? How do other file managers do it?