| Summary: | Hovering over .CR2 (camera raw) files with the information panel on crashes dolphin | ||
|---|---|---|---|
| Product: | [Unmaintained] kio | Reporter: | Philip Muškovac <yofel> |
| Component: | general | Assignee: | Jos van den Oever <jos> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | crash | CC: | adawit, alexander.nofamilyname, bugzilla, cfeck, christos.lazaridis+kde.bugzilla, harald.koch, LLLActive, peter.penz19, v.babosha |
| Priority: | NOR | Keywords: | triaged |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 4.7.0 | |
| Sentry Crash Report: | |||
| Attachments: |
These are the first 65536 of the CR2 test file.
New crash information added by DrKonqi New crash information added by DrKonqi |
||
|
Description
Philip Muškovac
2011-04-07 22:11:16 UTC
If possible, please provide a link to that .CR2 file (or any other file that causes the same crash). @Peter, is there a command line utility to read Strigi meta data from a file, so that we can eventually get backtraces when trying to reproduce on trunk? Here's one: http://yofel.dyndns.org/misc/_MG_0809.CR2 @Christoph: xmlindexer should work for this (but I've never used it myself). It is important to clip the file to 64 KB before testing it, as this kind of limitation is where some Strigi analysers fail. A Strigi developer send me a mail some time ago where he tested it like this: $ split -b64K oha-common-lib-2.0-SNAPSHOT.jar $ xmlindexer xaa > /tmp/foo Okey, I tried to reproduce with the test file and the steps from comment #3. xmlindexer correctly outputs (among others) "nfo#width" and "nfo#height" tags with their 3888 and 2592 values on the xaa file. Dolphin, however, shows no metadata, so I assume that something there crashes even while xmlindexer does not. That's why I am not so sure that Strigi is to blame in this case. I also tried renaming the 64K xaa file to xaa.tiff or xaa.CR2, but Dolphin and the file properties dialog refuse to show any metadata. @Christoph: I think the backtrace shows clear that the Strigi analyzer is crashing. Did you assure that 64 KB are used? Probably xmlindexer behaves different with 64 KB in comparison to limiting the stream to 64 KB like done in KFileMetaInfo. If limiting vs. clipping would make a difference, then Dolphin would show meta info for the xaa.CR2 file (which is exactly 65536 bytes large). xmlindexer does. Created attachment 58714 [details]
These are the first 65536 of the CR2 test file.
Hm, I get a reproducible crash in the analyzer when reading the metadata of your attachment. I did not say that the 64 KB limit is necessary for crashing an analyzer (it just turned out that it is quite often the rootcause)... The code in KFileMetaInfo to access the Strigi analyzers was written by Jos van den Oever himself and I don't know how it is different to the code in xmlindexer - probably the analyzer crashes too in the xmlindexer but the xmlindexer just outputs all values that have been read already? Wild guesses of course, but I must admit that after 3 years of those metadata crashes my motivation to investigate into them further is not very high ;-) (see http://ppenz.blogspot.com/2011/03/dont-crash-when-reading-metadata.html for more info - so at least in Dolphin for 4.7 it won't crash anymore). I got in contact with some Strigi developers a few weeks ago and they could reproduce the crashes also with the xmlindexer, however it seems some analyzers are unmaintained and won't be fixed :-/ Is there a way to completely preventing dolphin to attempt reading metadata on CR2 files as a workaround until (if) a fix is provided? I use it quite a bit and it makes dolphin pretty much unusable as a file manager when dealing with photos. > Is there a way to completely preventing dolphin to attempt > reading metadata on CR2 files as a workaround until (if) a fix is provided? Yes, please turn off tooltips and the information panel. This is an issue in the corresponding Strigi analyzer that Dolphin uses to get the metadata of a file. Dolphin for KDE 4.7 won't crash anymore in this case (see http://ppenz.blogspot.com/2011/03/dont-crash-when-reading-metadata.html for details). We keep this bug open until we know why KFileMetaInfo crashes, while xmlindexer does not. Created attachment 63782 [details] New crash information added by DrKonqi dolphin (1.6) on KDE Platform 4.6.00 (4.6.0) "release 6" using Qt 4.7.1 - What I was doing when the application crashed: Dolphin crash when I try to preview .cr2 from archive with Darktable handbook (http://sourceforge.net/projects/darktable/files/darktable/book/1.0/). Files from my EOS 450D can be previwed normally. -- Backtrace (Reduced): #7 0x00007f8cd158f6e9 in (anonymous namespace)::strigi_tiffReadProc (handle=<value optimized out>, buf=0x7f8cd4196050, size=<value optimized out>) at /usr/include/bits/string3.h:52 #8 0x0000003868629c51 in OJPEGReadBufferFill (sp=0x7f8cd4195a70) at tif_ojpeg.c:1885 #9 0x000000386862ac08 in OJPEGReadBytePeek (tif=0x7f8cd41950f0) at tif_ojpeg.c:1965 #10 OJPEGReadHeaderInfoSec (tif=0x7f8cd41950f0) at tif_ojpeg.c:1231 #11 0x000000386862bdd6 in OJPEGSubsamplingCorrect (tif=0x7f8cd41950f0) at tif_ojpeg.c:959 *** This bug has been confirmed by popular vote. *** Created attachment 65868 [details] New crash information added by DrKonqi konqueror (4.6.5 (4.6.5) "release 7") on KDE Platform 4.6.5 (4.6.5) "release 7" using Qt 4.7.1 - What I was doing when the application crashed: Hovering over a specific .CR2 File in Konqueror from a Canon EOS 7D. OpenSUSE 11.4, 64bit The File can be retrieved from http://www.matthias-keller.ch/konqueror-crash/IMG_0355.CR2 This bug may or may not be related to #260872. I tried using another version of libstrigi0 (the one from the ISO: 0.7.3.99-0.2-x86_64 as well as the one from KDE SC 4.6 repo 0.7.3.99-2.18-x86_64 - they both show the same behavior in konqueror. -- Backtrace (Reduced): #7 0x00007ff82245e6e9 in (anonymous namespace)::strigi_tiffReadProc (handle=<value optimized out>, buf=0xf822c0, size=<value optimized out>) at /usr/include/bits/string3.h:52 #8 0x00007ff8293f5c51 in OJPEGReadBufferFill (sp=0xf81ce0) at tif_ojpeg.c:1885 #9 0x00007ff8293f6c08 in OJPEGReadBytePeek (tif=0xf85750) at tif_ojpeg.c:1965 #10 OJPEGReadHeaderInfoSec (tif=0xf85750) at tif_ojpeg.c:1231 #11 0x00007ff8293f7dd6 in OJPEGSubsamplingCorrect (tif=0xf85750) at tif_ojpeg.c:959 *** Bug 287695 has been marked as a duplicate of this bug. *** *** Bug 288855 has been marked as a duplicate of this bug. *** *** Bug 303805 has been marked as a duplicate of this bug. *** Strigi analyzers are no more in KDE v4.10 according to a posting by the current Nepomuk maintainer ; so can this bug report be closed now? [1] http://vhanda.in/blog/2013/05/we-need-more-indexers/ Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |