KDE4 apps are freezing from time to time if the home is in NFSv4 with Kerberos. Dolphin freezes if you try to Open an PDF. Okular is freezing if you try to save an PDF. Also a littel KDE Application (that only opens a file !) - just try to open a 2. files it freezes (3 -4 Min). source u can find here: http://techbase.kde.org/Development/Tutorials/Saving_and_loading I tested it with Kubuntu 13.10 OpenSuSE 13.1 OpenSuSE 12.3 Reproducible: Sometimes Steps to Reproduce: Steps to Reproduce: 1. home in NFS (in my case with Kerberos) rest see above Actual Results: App is freezing Actual Results: App freezes. Expected Results: App should not freeze.
Thanks for the bug report. (In reply to comment #0) > Okular is freezing if you try to save an PDF. Then it's obviously not a Dolphin bug. You can help to identify the code which causes the freeze by following these steps: http://community.kde.org/Dolphin/FAQ/Freeze Thanks for your help!
If you can provide the information requested in comment #1, please add it.
Created attachment 85022 [details] dbg ouput of Dolphin Threads I tryed as described on the freezing Page - found it Intressting that the Terminal with the GDB didnt react until the freez of the Dolphin stoped. - But here is the Backtrace:
Thanks. It looks like it hangs in utime, which is called from KIO. Thread 1 (Thread 0x7ffff7fa6780 (LWP 2563)): #0 0x00007ffff7889a67 in utime () from /lib64/libc.so.6 #1 0x00007ffff59abbb0 in KRecentDocument::add(KUrl const&, QString const&) () from /usr/lib64/libkio.so.5 #2 0x00007ffff59050f6 in KRun::run(KService const&, KUrl::List const&, QWidget*, bool, QString const&, QByteArray const&) () from /usr/lib64/libkio.so.5 #3 0x00007ffff5908e2d in KRun::runUrl(KUrl const&, QString const&, QWidget*, bool, bool, QString const&, QByteArray const&) () from /usr/lib64/libkio.so.5 #4 0x00007ffff59094b7 in KRun::foundMimeType(QString const&) () from /usr/lib64/libkio.so.5 #5 0x00007ffff58fef92 in KRun::mimeTypeDetermined(QString const&) () from /usr/lib64/libkio.so.5 #6 0x00007ffff5907b26 in KRun::init() () from /usr/lib64/libkio.so.5 #7 0x00007ffff5900e10 in KRun::slotTimeout() () from /usr/lib64/libkio.so.5 #8 0x00007ffff4946f5f in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib64/libQtCore.so.4 #9 0x00007ffff4944edc in QObject::event(QEvent*) () from /usr/lib64/libQtCore.so.4 #10 0x00007ffff3a6074c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4 #11 0x00007ffff3a64c7a in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4 #12 0x00007ffff538c006 in KApplication::notify(QObject*, QEvent*) () from /usr/lib64/libkdeui.so.5 #13 0x00007ffff493073e in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/libQtCore.so.4
OK - so that means KIO is the problem, is there a possibility to report that bug to the KIO group ?
(In reply to comment #5) > OK - so that means KIO is the problem, is there a possibility to report that > bug to the KIO group ? It has been reassigned already - see the "Product" field.
This is literally why network mounted directories are so horrible. The code that causes it to freeze according to the backtrace you provided is utime. In this case that code is attempting to update the access and modification timestamps on the file you are trying to open. The only way that would block is if it cannot access the file and that happens because the mounted directory is not available for whatever reason, network issue or one of the many other problems with network mounts.
I have had the same problem (Ubuntu Vivid (3.19.0-15-generic) as client, Trusty (3.13.0-46-generic) as server). I did some searching and found this post https://lkml.org/lkml/2012/8/15/13 With the supplied code, I was able to verify the problem. After some more searching I've found a more recent post on the linux-nfs mailinglist http://www.spinics.net/lists/linux-nfs/msg39040.html Solution (http://www.spinics.net/lists/linux-nfs/msg39106.html): Use NFS 4.1 (mount with -o minorversion=1). This seems to fix all hangs in various KDE applications.
Is this still relevant or applicable with KDE Frameworks 5.45?
As far as I can tell, the hang in utime() was never a bug in KDE software, but in the kernel/NFS.
Thanks!