after upgrading the kde packages to 5.13.0 (arch) whenever I started dolphin the program hung forever and was not responsive at all -- even directly after execution -- so that I had to switch to nautilus for a few days. I recognized from the strace below the problem occured that the dolphin startup blocked after reading (forever) the file .lyxpipe.in in my home directory. deleting that file (I have no idea whether this was a good idea ;)) then made dolphin hang again but now at the file .lyxpipe.out . when I deleted also that file dolphin was able to start normally again. if important i had enabled 1) show hidden files/dirs and 2) the console emulation in the bottom of the dolphin window the relevant strace output: [augustin@asterope ~]$ strace dolphin execve("/usr/bin/dolphin", ["dolphin"], [/* 59 vars */]) = 0 [...] stat("/home/augustin/.lyxpipe.in", {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 lstat("/home/augustin/.lyxpipe.in", {st_mode=S_IFLNK|0777, st_size=40, ...}) = 0 open("/home/augustin/.lyxpipe.in", O_RDONLY|O_CLOEXEC) = 22 fcntl(22, F_SETFD, FD_CLOEXEC) = 0 fstat(22, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0 fstat(22, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 read(22, => now dolphin hang forever Reproducible: Always Steps to Reproduce: 1. open dolphin Actual Results: program hangs Expected Results: program is responsive workaround inside
Thanks for the bug report! To find out what part of the code is responsible for the hang (it might not be in Dolphin at all, but in some library), we need a backtrace of the freeze. Can you reproduce the problem by restoring the file(s)? See https://community.kde.org/Dolphin/FAQ/Freeze for details. Thanks for your help.
unfortunately I did not move the files but really deleted them. thus I cannot restore the original files (since my nightly backup already includes the deletion). interestingly: creating new .lyxpipe.in and .out files by using the program "lyx" does not lead to the same problem of a hanging dolphin. maybe the problem was that those files referred to "zombie" pipes, whatever this is?! sorry that I cannot give the backtrace...
I'm afraid there is nothing we can do about this issue then :-( If you or anyone else sees this issue again and can provide a backtrace, please add a comment here or file a new bug report. Thanks!
the problem appeared again (after using kile) and I could now run a backtrace. problematic files: [augustin@asterope ~]$ ls -la | grep lyxpipe lrwxrwxrwx 1 augustin users 40 24. Sep 16:41 .lyxpipe.in -> /tmp/kde-augustin/kilejTARU8/.lyxpipe.in lrwxrwxrwx 1 augustin users 41 24. Sep 16:41 .lyxpipe.out -> /tmp/kde-augustin/kilejTARU8/.lyxpipe.out backtrace, copied from "thread apply all backtrace" within "gdb dolphin" + CTRL-Z (in a hanging situation due to those .lyxpipe* files): Thread 4 (Thread 0x7fffd68f9700 (LWP 19537)): #0 0x00007fffece43428 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x00007ffff1a28c66 in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQt5Core.so.5 #2 0x00007ffff1a24723 in ?? () from /usr/lib/libQt5Core.so.5 #3 0x00007ffff1a27a9e in ?? () from /usr/lib/libQt5Core.so.5 #4 0x00007fffece3d4a4 in start_thread () from /usr/lib/libpthread.so.0 #5 0x00007ffff784313d in clone () from /usr/lib/libc.so.6 Thread 3 (Thread 0x7fffd7fff700 (LWP 19529)): #0 0x00007ffff783a18d in poll () from /usr/lib/libc.so.6 #1 0x00007fffec70ac7c in ?? () from /usr/lib/libglib-2.0.so.0 #2 0x00007fffec70ad8c in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x00007ffff1c5f23f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #4 0x00007ffff1c0626a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #5 0x00007ffff1a22af4 in QThread::exec() () from /usr/lib/libQt5Core.so.5 #6 0x00007ffff1a27a9e in ?? () from /usr/lib/libQt5Core.so.5 #7 0x00007fffece3d4a4 in start_thread () from /usr/lib/libpthread.so.0 #8 0x00007ffff784313d in clone () from /usr/lib/libc.so.6 Thread 2 (Thread 0x7fffdedee700 (LWP 19528)): #0 0x00007ffff783a18d in poll () from /usr/lib/libc.so.6 #1 0x00007fffea5c4ae2 in ?? () from /usr/lib/libxcb.so.1 #2 0x00007fffea5c6757 in xcb_wait_for_event () from /usr/lib/libxcb.so.1 #3 0x00007fffe1156ca9 in ?? () from /usr/lib/libQt5XcbQpa.so.5 #4 0x00007ffff1a27a9e in ?? () from /usr/lib/libQt5Core.so.5 #5 0x00007fffece3d4a4 in start_thread () from /usr/lib/libpthread.so.0 #6 0x00007ffff784313d in clone () from /usr/lib/libc.so.6 Thread 1 (Thread 0x7ffff7ebf800 (LWP 19524)): #0 0x00007ffff783616d in read () from /usr/lib/libc.so.6 #1 0x00007ffff1b82f2d in ?? () from /usr/lib/libQt5Core.so.5 #2 0x00007ffff1b94ffe in ?? () from /usr/lib/libQt5Core.so.5 #3 0x00007ffff1b2836d in QFileDevice::readData(char*, long long) () from /usr/lib/libQt5Core.so.5 #4 0x00007ffff1b3166c in QIODevice::read(char*, long long) () from /usr/lib/libQt5Core.so.5 #5 0x00007ffff1b31b15 in QIODevice::read(long long) () from /usr/lib/libQt5Core.so.5 #6 0x00007ffff1b31bdd in QIODevicePrivate::peek(long long) () from /usr/lib/libQt5Core.so.5 #7 0x00007ffff1b32e32 in QIODevice::peek(long long) () from /usr/lib/libQt5Core.so.5 #8 0x00007ffff1c8755d in ?? () from /usr/lib/libQt5Core.so.5 #9 0x00007ffff1c87de4 in QMimeDatabase::mimeTypeForFile(QFileInfo const&, QMimeDatabase::MatchMode) const () from /usr/lib/libQt5Core.so.5 #10 0x00007ffff1c8817d in QMimeDatabase::mimeTypeForFile(QString const&, QMimeDatabase::MatchMode) const () from /usr/lib/libQt5Core.so.5 #11 0x00007ffff1c88671 in QMimeDatabase::mimeTypeForUrl(QUrl const&) const () from /usr/lib/libQt5Core.so.5 #12 0x00007ffff5803a58 in KFileItem::determineMimeType() const () from /usr/lib/libKF5KIOCore.so.5 #13 0x00007ffff749bc74 in KFileItemModelRolesUpdater::applyResolvedRoles(int, KFileItemModelRolesUpdater::ResolveHint) () from /usr/lib/libdolphinprivate.so.5 #14 0x00007ffff749ed43 in KFileItemModelRolesUpdater::resolveNextPendingRoles() () from /usr/lib/libdolphinprivate.so.5 #15 0x00007ffff751dfe5 in ?? () from /usr/lib/libdolphinprivate.so.5 #16 0x00007ffff1c37eb1 in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5 #17 0x00007ffff2dd300c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #18 0x00007ffff2dd84e6 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #19 0x00007ffff1c0889b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5 #20 0x00007ffff1c0ac96 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt5Core.so.5 #21 0x00007ffff1c5ee33 in ?? () from /usr/lib/libQt5Core.so.5 #22 0x00007fffec70a9fd in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #23 0x00007fffec70ace0 in ?? () from /usr/lib/libglib-2.0.so.0 #24 0x00007fffec70ad8c in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #25 0x00007ffff1c5f23f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #26 0x00007ffff1c0626a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #27 0x00007ffff1c0e20c in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5 #28 0x00007ffff7b5dda4 in kdemain () from /usr/lib/libkdeinit5_dolphin.so #29 0x00007ffff777a610 in __libc_start_main () from /usr/lib/libc.so.6 #30 0x0000000000400779 in _start ()
Thanks. This looks like a bug in Qt. In order to forward it to the Qt bug tracker and possibly investigate it, we need the file.
The file ~/.lyxpipe.in (.out accordingly) is a symlink to the file /tmp/kde-augustin/kilejTARU8/.lyxpipe.in which itself is a "fifo (named pipe)" according to the output of the program "file": bash$ file /tmp/kde-augustin/kilejTARU8/.lyxpipe.in /tmp/kde-augustin/kilejTARU8/.lyxpipe.in: fifo (named pipe) I have no idea how to send a pipe file and do not think this is possible at all. Please help me :-)
> I have no idea how to send a pipe file and do not think this is possible at all. Please help me :-) Yep this isn't possible ;) Please try to write something into the pipe (echo "some bits to unfreeze" > .lyxpipe.in) while Dolphin is hanging, this should unfreeze Dolphin ;) (and maybe close Kile before you try it) QMimeDatabase::mimeTypeForFile wants to be smart and tries to read the header of the pipe file to determine the exact mime type of it, which isn't great in case of pipes -> blocks until new data arrives.
thanks! when writing lots of data into the pipe dolphin is unfreezed (for example cat /dev/urandom > .lyxpipe.in). however, when writing only a few times your line into the pipe the blocking continues. the blocking only occurs if hidden files and directories are visible in dolphin. interestingly even just renaming the symlink .lyxpipe.in. into .lyxpipe.in.bak which is still in the same shown home directory (and similar for .lyxpipe.out) will resolve the issue for new dolphin instances (though not for already blocking ones)
There is already a bug report for Qt, will mark this as resolved upstream. https://bugreports.qt.io/browse/QTBUG-48529
*** Bug 354740 has been marked as a duplicate of this bug. ***
*** Bug 352031 has been marked as a duplicate of this bug. ***
Fixed in Qt 5.6.0.