SUMMARY see $SUBJECT STEPS TO REPRODUCE 1. create (e.g.) SMB mount in /etc/fstab, user mountable, mount it 2. start dolphin, but do not (necessarily) access this share 3. kill connection to server via pulling the cable from the *server* (so that the PC still has a link, but it doesn't go anywhere) OBSERVED RESULT Dolphin freezes after a few clicks, does not recover, has to be killed. Newly started Dolphin process also freezes quickly. EXPECTED RESULT Dolphin should put all accesses to non-local mount points in a separate thread which can timeout after some time and do not block the main application. If shares become unavailable (due to I/O errors, network stalling, or whatever) the shares should be set "offline" until explicitly clicked on again. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 20.10 with all updates applied.
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.