Version: (using Devel) Compiler: GCC 4.4.0 OS: Linux Installed from: Compiled sources Dolphin seems to freeze on general file browsing and then does eventually work as normal again(20/30 seconds later). Previews are enabled. dmesg shows the following output and is spurted out rather a lot. kio_thumbnail[3190]: segfault at f68 ip 00007fce43354b87 sp 00007fff0e3585c0 error 4 in libgcc_s.so.1[7fce43345000+16000]
This seems like a kdelibs bug, since it's the kio_thumbnail process that is causing the issues. This is pretty serious as it can freezes Plasma as well and also (not that's your issue) GTK dialogs.
Extra info; This seems to be the thumbnails enabled on the folders. If I turn folder thumbnails off it's fine.
Exactly the same problem over here! * Dolphin 1.2.80 from KDE 4.2.95 on Kubuntu * gcc-Version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) * Kernel 2.6.28-13-generic (x86_64)
Thanks for the info! I cannot reproduce the issue: Does this issue appear all the time or only occasionally on specific kind of folders? @Martin: does turning off folder thumbnails solve the issue too for you? (the previews can be turned off in the Dolphin settings -> General -> Previews -> [ ] Directories)
Turned it off for folders now. Immediately works a lot faster and no more segfaults. Thanks!
(In reply to comment #4) > Thanks for the info! I cannot reproduce the issue: Does this issue appear all > the time or only occasionally on specific kind of folders? Just thumbnail folder previews and kio_thumbnail starts in the process and starts to freeze dolphin or the file dialogs.
Hi, It happens here too. It seems to me that It happens when moving mouse over a dir (or a file) that does not contain an image inside to show as preview. however dolphin itself is not freezing for me or crashing apart the kio-thumbnail segfault triggered. using dolphin Version 1.3 Using KDE 4.2.96 (KDE 4.2.96 (KDE 4.3 RC2)) (KDEmod) on archlinux thanks Peter , I really enjoy dolphin!
The same problem (+total plasma freeze, 10-20 sec). OS - Gentoo kde - 4.2.96 compiled from sources. i686-pc-linux-gnu-4.3.2 qt-4.5.1
I can confirm the bug is only triggered when Directory thumbnail plugin is activated. I managed to get a core dump of the bug. I wrote a kernel module to set the core size rlimit to infinity for kdeinit4 (the parent process that spawns all the kio_file slaves), then killed all the slaves so kdeinit would spawn new ones that would inherit kdeinit4's core size limit. Also changed /proc/sys/kernel/core_pattern and /proc/sys/kernel/core_uses_pid to save core files somewhere in /tmp with pid suffix (just to be sure, cwd of kdeinit is user's home dir by default). I would be happy to post the code and instructions on how to get this kind of core dumps, but I'm not sure where it would be best to post this. Anyway, loaded the core dump using the /usr/bin/kdeinit4 binary and here is the back trace: #0 uw_frame_state_for (context=0x7fff66b2a8f0, fs=<value optimized out>) at ../../../src/libgcc/../gcc/config/i386/linux-unwind.h:51 #1 0x00007f875b230dbb in _Unwind_Backtrace (trace=0x7f875afa94f0 <backtrace_helper>, trace_argument=0x7fff66b2aa20) at ../../../src/libgcc/../gcc/unwind.inc:295 #2 0x00007f875afa9612 in *__GI___backtrace (array=<value optimized out>, size=256) at ../sysdeps/x86_64/../ia64/backtrace.c:85 #3 0x00007f875e122828 in kRealBacktrace (levels=-1) at /build/buildd/kde4libs-4.2.96/kdecore/io/kdebug.cpp:594 #4 0x00007f875ccacd7e in ~KIconLoader (this=0x1effc30) at /build/buildd/kde4libs-4.2.96/kdecore/io/kdebug.h:98 #5 0x00007f875aee46ed in *__GI_exit (status=1) at exit.c:75 #6 0x00007f875d7e2674 in sigsegv_handler (sig=11) at /build/buildd/kde4libs-4.2.96/kio/kio/slavebase.cpp:745 #7 <signal handler called> #8 0x0000000000000f68 in ?? () #9 0x00007f875bcba7ab in QPainter::end (this=<value optimized out>) at painting/qpainter.cpp:1853 #10 0x00007f875bcba8e8 in ~QPainter (this=0x7fff66b2bc00) at painting/qpainter.cpp:1414 #11 0x00007f875252c69b in ThumbnailProtocol::thumbForDirectory (this=0x7fff66b2c750, directory=<value optimized out>) at /build/buildd/kdebase-runtime-4.2.96/kioslave/thumbnail/thumbnail.cpp:648 #12 0x00007f875252db97 in ThumbnailProtocol::get (this=0x7fff66b2c750, url=@0x7fff66b2c550) at /build/buildd/kdebase-runtime-4.2.96/kioslave/thumbnail/thumbnail.cpp:247 #13 0x00007f875d7e7005 in KIO::SlaveBase::dispatch (this=0x7fff66b2c750, command=67, data=@0x7fff66b2c690) at /build/buildd/kde4libs-4.2.96/kio/kio/slavebase.cpp:1012 #14 0x00007f875d7e7664 in KIO::SlaveBase::dispatchLoop (this=0x7fff66b2c750) at /build/buildd/kde4libs-4.2.96/kio/kio/slavebase.cpp:282 #15 0x00007f875252b0f2 in kdemain (argc=4, argv=0x1eefda0) at /build/buildd/kdebase-runtime-4.2.96/kioslave/thumbnail/thumbnail.cpp:136 #16 0x0000000000407215 in launch (argc=4, _name=0x1ef3e08 "kio_thumbnail", args=<value optimized out>, cwd=0x0, envc=0, envs=0x1ef3e92 "", reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x40a3c9 "0") at /build/buildd/kde4libs-4.2.96/kinit/kinit.cpp:676 #17 0x0000000000407a38 in handle_launcher_request (sock=7, who=<value optimized out>) at /build/buildd/kde4libs-4.2.96/kinit/kinit.cpp:1168 #18 0x0000000000407fe5 in handle_requests (waitForPid=0) at /build/buildd/kde4libs-4.2.96/kinit/kinit.cpp:1361 #19 0x0000000000408b26 in main (argc=2, argv=0x7fff66b2d558, envp=0x7fff66b2d570) at /build/buildd/kde4libs-4.2.96/kinit/kinit.cpp:1788 The SEGV seems to happen in the destructor of the QPainter object created on line 537 in kdebase/runtime/kioslave/thumbnail/thumbnail.cpp, destructor that is called just before the return statement of ThumbnailProtocol::thumbForDirectory: http://websvn.kde.org/trunk/KDE/kdebase/runtime/kioslave/thumbnail/thumbnail.cpp?view=annotate#l537 Here's the sequence of events as I see it: - line 534: img = QImage(...) // img is constructed - line 537: QPainter p(&img) // p is constructed on device img - line 645: img = QImage(); // no thumb, replace img with empty one - line 648: return img; // automatic class destructors are called Most likely, the compiler first calls the destructor for the original img object created on line 534, which is the one that is used by the QPainter object. THEN, it calls the destructor for the QPainter object; the destructor calls QPainter::end, which tries to access an object that was created by the img... http://qt.gitorious.org/qt/qt/blobs/4.5/src/gui/painting/qpainter.cpp#line1863 (lines are offet with about +9 from the back trace, not sure why) ... but that object was already destroyed by the destructor => SEGV. My simple fix is to enclose all the code from before the creation of the QPainter object until before the return, so that the QPainter destructor is called before the QImage destructor. I attached a patch, but I must say that I didn't try it / compile with it, so I apologize if it doesn't work. But it should work :) Octavian
Created attachment 35406 [details] Wraps the code that uses the QPainter object so its destructor is called before those of QImage
Anybody checked out the patch I sent? I tried to recompiled the kdebase-runtime package (with no patches except the standard ones), but when I installed them (with dpkg --ignore-deps=kdebase-runtime) thumbnails weren't working at all. Also tried just replacing the kio_thumbnail.so lib and the same result. Not exactly sure what I'm doing wrong... Anyway, this has nothing to do with the patch and I really think it would work. Just to show you how serious this is: $ zgrep kio_thumbnail /var/log/* | wc -l 7632
SVN commit 1001953 by ppenz: Backport: Fix possible crash in QPainter destructor when accessing 'img'. Thanks to Octavian for the analysis! CCBUG: 196880 M +5 -1 thumbnail.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1001953
@Octavian: Thanks for the analysis! I've just committed a patch to trunk and KDE 4.3.x branch. As I could not reproduce the crash before, I don't want to set this issue to resolved until someone could check whether this patch really fixes the reported issue.
I recompiled kio_thumbnail.so from sources, using the KDE 4.3 branch (patch was included) and the bug was still present. A backtrace revealed that the fault indeed occurred in end() call, and no destructor was in the call stack. My guess is that the destructor is called immediately after `img = QImage()', because the compiler thinks there's no way to access that reference anymore. I moved the `p.end()' instruction just before the code that replaced the img object with an empty one, recompiled and it seems this works -- the bug is not triggered anymore. I'm attaching the patch (must be applied to the latest version of the file, revision 1001953 that is).
Created attachment 35631 [details] Fix for the QPainter destructor issue Should be applied to latest version, with changes in rev 1001953. I tested it and I can confirm it fixes the issue.
SVN commit 1002368 by ppenz: Fix crash in QPainter::end() if no thumbnail could be generated (patch written and tested by Octavian). BUG: 196880 M +2 -2 thumbnail.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1002368
SVN commit 1002369 by ppenz: Backport of SVN commit 1002368: Fix crash in QPainter::end() if no thumbnail could be generated (patch written and tested by Octavian). CCBUG: 196880 M +2 -2 thumbnail.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1002369
Thanks Octavian!