Created attachment 55125 [details] screenshot right before crash Version: unspecified (using KDE 4.5.4) OS: Linux When clicking once on, or hovering over, a certain CR2 image, Dolphin crashes. Here is the terminal output: $ dolphin QMetaObject::invokeMethod: No such method DolphinApplication::loadCommandLineOptionsForNewInstance() dolphin(18918) KXMLGUI::ActionList::plug: Index 85 is not within range (0 - 33 $ IMG_0229.CR2: Warning, incorrect count for field "BitsPerSample" (3, expecting 1); tag trimmed. TIFFReadDirectory: Warning, Photometric tag is missing, assuming data is YCbCr. TIFFReadDirectory: Warning, SamplesPerPixel tag is missing, assuming correct SamplesPerPixel value is 3. KCrash: Application 'dolphin' crashing... KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit sock_file=/home/alouqua/.kde4/socket-kiwiarch/kdeinit4__0 QSocketNotifier: Invalid socket 5 and type 'Read', disabling... QSocketNotifier: Invalid socket 14 and type 'Read', disabling... dolphin: Fatal IO error: client killed Reproducible: Always Steps to Reproduce: Open dolphin, navigate to the directory with the image, then click once on it or hover the mouse over it (which would typically show some info in the info-panel) Actual Results: crash Expected Results: should just show some info in the info-panel I of course have previews on of CR2 files.
http://bit.ly/hfINCt has the test image that crashes, other CR2 files seem to preview fine.
[Comment from a bug triager] I could reproduce the crash with the image. I don't have a complete backtrace but it is related to Strigi and libtiff (3.9.4 here) - Incomplete backtrace: (gdb) bt #0 0xb7e54616 in memcpy () from /lib/libc.so.6 #1 0xb1d138f0 in ?? () #2 0xb31e1222 in ?? () from /usr/lib/libtiff.so.3 #3 0xb31e20a8 in ?? () from /usr/lib/libtiff.so.3 #4 0xb31e30b9 in ?? () from /usr/lib/libtiff.so.3 #5 0xb31e3326 in ?? () from /usr/lib/libtiff.so.3 #6 0xb31c36ae in TIFFVGetField () from /usr/lib/libtiff.so.3 #7 0xb31c36eb in TIFFGetField () from /usr/lib/libtiff.so.3 #8 0xb31eece4 in TIFFScanlineSize () from /usr/lib/libtiff.so.3 #9 0xb31c6482 in TIFFReadDirectory () from /usr/lib/libtiff.so.3 #10 0xb31e545c in TIFFClientOpen () from /usr/lib/libtiff.so.3 #11 0xb1ebb643 in ?? () from /usr/lib/strigi/strigiea_tiff.so #12 0xb5f9734a in ?? () from /usr/lib/libstreamanalyzer.so.0 #13 0xb781bdce in ?? () from /usr/lib/libkio.so.5 #14 0xb781c71d in KFileMetaInfo::KFileMetaInfo(QString const&, QString const&, QFlags<KFileMetaInfo::What>) () from /usr/lib/libkio.so.5 #15 0xb78fc401 in ?? () from /usr/lib/libkio.so.5 #16 0xb63ea5f9 in ?? () from /usr/lib/libQtCore.so.4 #17 0xb61fee60 in start_thread () from /lib/libpthread.so.0 #18 0xb7eacf9e in clone () from /lib/libc.so.6 This is probably related to bug 254594. Regards
Created attachment 56785 [details] New crash information added by DrKonqi konqueror (4.6.00 (4.6.0) "release 375") on KDE Platform 4.6.00 (4.6.0) "release 375" using Qt 4.7.1 - What I was doing when the application crashed: As soon as I hover a CR2 (Canon EOS 400D RAW image) file, the application crashes. This happens always and is very annoying, since I can't manage my photographs with Konqueror/Dolphin. The bug exists since a long time ago; it already existed in KDE 4.4.x and is still present in KDE 4.6.0. I tried with libtiff 3.9.2 and 3.9.4 and it always crashes. -- Backtrace (Reduced): #7 0x00007f426ebd3639 in (anonymous namespace)::strigi_tiffReadProc (handle=<value optimized out>, buf=0x119fb80, size=<value optimized out>) at /usr/include/bits/string3.h:52 #8 0x00007f427c59fc21 in OJPEGReadBufferFill (sp=0x119f5a0) at tif_ojpeg.c:1880 #9 0x00007f427c5a0bd8 in OJPEGReadBytePeek (tif=0x11a49c0) at tif_ojpeg.c:1960 #10 OJPEGReadHeaderInfoSec (tif=0x11a49c0) at tif_ojpeg.c:1231 #11 0x00007f427c5a1d66 in OJPEGSubsamplingCorrect (tif=0x11a49c0) at tif_ojpeg.c:959
*** Bug 254594 has been marked as a duplicate of this bug. ***
Just one point: the crash happens always and with any CR2 file. It looks like the typical "write to invalid memory" crash that can easily be fixed because it can always be reproduced. Here is a sample image that triggers the crash: http://www.erasmus-innsbruck.com/IMG_2422.CR2 The crash doesn't happen if you select the image with the keyboard arrows (and thus, don't hover it). It also doesn't happen if you select the image in the file selector. If the image is in a remote file system (e.g. fish), the crash doesn't happen. But as soon as you hover a local CR2 with the mouse in Dolphin/Konqueror, boom!
> -- Backtrace (Reduced): > #7 0x00007f426ebd3639 in (anonymous namespace)::strigi_tiffReadProc > (handle=<value optimized out>, buf=0x119fb80, size=<value optimized out>) at > /usr/include/bits/string3.h:52 > #8 0x00007f427c59fc21 in OJPEGReadBufferFill (sp=0x119f5a0) at > tif_ojpeg.c:1880 BTW, this is libtiff 3.9.4, that I installed from download.opensuse.org/factory-tested. But it also happens with the standard libtiff 3.9.2 from openSUSE 11.3.
Thanks for the updated information. The root-cause for this is an issue in Strigi. I've created a bug-report for Strigi at https://sourceforge.net/tracker/?func=detail&aid=3170517&group_id=171000&atid=856302
I guess this is the 64k limit imposed by KFileMetaInfo again and libstrigi fails catching that...
(In reply to comment #7) > Thanks for the updated information. The root-cause for this is an issue in > Strigi. I've created a bug-report for Strigi at > https://sourceforge.net/tracker/?func=detail&aid=3170517&group_id=171000&atid=856302 On KDE with disabled Strigi service Dolphin still crashes with CR2-previews.
[Comment from a bug triager] In the KDE settings you can disable Strigi for Nepomuk; but Strigi will still be used when retrieving meta-information on the fly (hovering a file or rightclicking->Properties). That's why it still crashes in your computer. Regards
12.02.2011 14:26, Dario Andres пишет: > https://bugs.kde.org/show_bug.cgi?id=260872 > > > > > > --- Comment #10 from Dario Andres<andresbajotierra gmail com> 2011-02-12 12:26:48 --- > [Comment from a bug triager] > In the KDE settings you can disable Strigi for Nepomuk; but Strigi will still > be used when retrieving meta-information on the fly (hovering a file or > rightclicking->Properties). That's why it still crashes in your computer. > Regards > How I can wokaround this most annoying bug of Dolphin? Status of this BUG in bugtracker is "RESOLVED as UPSTREAM". Is it means that in "upstream" strigi integration removed from Doplhin?
[Comment from a bug triager] "UPSTREAM" means that the bug is inside some library used by the application. In this case, the bug is inside the strigi library which is used in the Dolphin application. The bug was already reported to the Strigi developers and they should take care of it. (that's why the report is closed as UPSTREAM) A possible workaround is: - Disable tooltips (they fetch meta-information) - Disable the "Information panel" (it fetches metainformation when hovering file) Regards
12.02.2011 15:16, Dario Andres пишет: > --- Comment #12 from Dario Andres<andresbajotierra gmail com> 2011-02-12 13:16:44 --- > [Comment from a bug triager] > A possible workaround is: > - Disable tooltips (they fetch meta-information) > - Disable the "Information panel" (it fetches metainformation when hovering > file) Thank you! It's works for me.