Created attachment 63252 [details]
PDF which causes crash

Thanks for the detailed backtrace. Once we have a strigi maintainer again, it should be possible to reproduce and fix with the attached document.

Not sure if it's related, but this RAW image: http://ur1.ca/50sfw (11M) also causes a crash in kfilemetadatareader each time I hover over it ("program-id 8285", sorry I don't have debug packages installed, rather a drag on Arch Linux). 

Note: I don't have Nepomuk/Strigi running.

(Nice that Dolphin is now robust enough to survive these minor crashes =D)

(In reply to comment #3)
> Not sure if it's related, but this RAW image: http://ur1.ca/50sfw (11M) also
> causes a crash in kfilemetadatareader each time I hover over it ("program-id
> 8285", sorry I don't have debug packages installed, rather a drag on Arch
> Linux).

This RAW file makes kmetadatafilereader crash herer, too, producing the following backtrace:
Application:  (kfilemetadatareader), signal: Segmentation fault
[KCrash Handler]
#6  memcpy () at ../sysdeps/x86_64/memcpy.S:267
#7  0x00007f0cfff075ac in (anonymous namespace)::strigi_tiffReadProc (handle=<value optimized out>, buf=0x8083c8, size=<value optimized out>) at /usr/include/bits/string3.h:52
#8  0x00007f0cffccd2ff in OJPEGReadBufferFill (sp=0x807dd0) at tif_ojpeg.c:1880
#9  0x00007f0cffcce27e in OJPEGReadBytePeek (tif=0x807380) at tif_ojpeg.c:1960
#10 OJPEGReadHeaderInfoSec (tif=0x807380) at tif_ojpeg.c:1231
#11 0x00007f0cffccf2fa in OJPEGSubsamplingCorrect (tif=0x807380) at tif_ojpeg.c:959
#12 0x00007f0cffccf770 in OJPEGVGetField (tif=0x8083c8, tag=0, ap=<value optimized out>) at tif_ojpeg.c:466
#13 0x00007f0cffcb0678 in TIFFGetField (tif=0x8083c8, tag=0) at tif_dir.c:957
#14 0x00007f0cffcd992a in TIFFScanlineSize (tif=0x8083c8) at tif_strip.c:237
#15 0x00007f0cffcb50dc in TIFFReadDirectory (tif=0x807380) at tif_dirread.c:764
#16 0x00007f0cffcd1564 in TIFFClientOpen (name=<value optimized out>, mode=0x7f0cfff082ce "r", clientdata=<value optimized out>, readproc=<value optimized out>, writeproc=0x7f0cfff07500 <(anonymous namespace)::strigi_tiffWriteProc(thandle_t, tdata_t, tsize_t)>, seekproc=0x7f0cfff07503 <(anonymous namespace)::strigi_tiffSeekProc(thandle_t, toff_t, int)>, closeproc=0x7f0cfff07543 <(anonymous namespace)::strigi_tiffCloseProc(thandle_t)>, sizeproc=0x7f0cfff07546 <(anonymous namespace)::strigi_tiffSizeProc(thandle_t)>, mapproc=0x7f0cfff0754b <(anonymous namespace)::strigi_tiffMapProc(thandle_t, tdata_t*, toff_t*)>, unmapproc=0x7f0cfff0754e <(anonymous namespace)::strigi_tiffUnmapProc(thandle_t, tdata_t, toff_t)>) at tif_open.c:436
#17 0x00007f0cfff076fe in TiffEndAnalyzer::analyze (this=0x7d4c90, ar=..., in=0x6faad0) at /var/tmp/portage/kde-base/kdegraphics-strigi-analyzer-4.7.0/work/kdegraphics-strigi-analyzer-4.7.0/tiff/tiffendanalyzer.cpp:201
#18 0x00007f0d17378327 in Strigi::StreamAnalyzerPrivate::analyze (this=0x712ae0, idx=..., input=0x6faad0) at /var/tmp/portage/app-misc/strigi-9999/work/strigi-9999/libstreamanalyzer/lib/streamanalyzer.cpp:418
#19 0x00007f0d19d74a23 in KFileMetaInfoPrivate::init (this=<value optimized out>, stream=<value optimized out>, url=<value optimized out>, mtime=1315290794, w=<value optimized out>) at /var/tmp/portage/kde-base/kdelibs-4.7.0-r1/work/kdelibs-4.7.0/kio/kio/kfilemetainfo.cpp:259
#20 0x00007f0d19d76580 in KFileMetaInfo::KFileMetaInfo (this=0x7fffb31141b0, path=..., w=<value optimized out>) at /var/tmp/portage/kde-base/kdelibs-4.7.0-r1/work/kdelibs-4.7.0/kio/kio/kfilemetainfo.cpp:288
#21 0x000000000040301e in readFileMetaData (urls=<value optimized out>) at /var/tmp/portage/kde-base/kdelibs-4.7.0-r1/work/kdelibs-4.7.0/kio/kfile/kfilemetadatareaderprocess.cpp:85
#22 0x0000000000403d0c in readFileAndContextMetaData (urls=<value optimized out>) at /var/tmp/portage/kde-base/kdelibs-4.7.0-r1/work/kdelibs-4.7.0/kio/kfile/kfilemetadatareaderprocess.cpp:146
#23 0x0000000000404f0e in main (argc=<value optimized out>, argv=<value optimized out>) at /var/tmp/portage/kde-base/kdelibs-4.7.0-r1/work/kdelibs-4.7.0/kio/kfile/kfilemetadatareaderprocess.cpp:195

I can confirm this crash also in KDE 4.7.1

Created attachment 64101 [details]
New crash information added by DrKonqi

kfilemetadatareader () on KDE Platform 4.7.1 (4.7.1) using Qt 4.7.4

- What I was doing when the application crashed:

Hover a specific pdf (which i can attach since it's contains private data :/ )
This pdf seems to be generated by Adobe Illustrator CS3 /Acrobat Distiller 8.3.0 under windows from the proprietary data i get from okular
There's also some fonts integrated inside FPPBJM+ArialMT, FPPBKN+Arial-ItalicMT, LJMJOG+ArialMT, LJMJOH+Arial-BoldMT, LJMJPH+ArialNarrow

-- Backtrace (Reduced):
#8  0x00007f2214ddc42d in __gnu_cxx::__verbose_terminate_handler () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:93
#9  0x00007f2214dda646 in __cxxabiv1::__terminate (handler=<value optimized out>) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:39
#10 0x00007f2214dda673 in std::terminate () at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:49
#11 0x00007f2214dda77e in __cxxabiv1::__cxa_throw (obj=<value optimized out>, tinfo=<value optimized out>, dest=<value optimized out>) at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:83
#12 0x00007f2214d84190 in std::__throw_length_error (__s=<value optimized out>) at ../../../../libstdc++-v3/src/functexcept.cc:74

Hovering over any of my PDFs causes kfilemetadatareader to crash.

I can confirm this bug too in KDE 4.7.2 with Qt 4.7.4. I never had this bug before KDE 4.7.2. Seems it only happens when hovering .pdf files. I don't have nepomuk/strigi enabled and I'm using Arch Linux x64 and its official packages.

I can confirmed this for KDE 4.7.2 (didn't happen with 4.7.1 on my system).
I am using Gentoo and have Nepomuk and Strigi disabled. Maybe that's causing the crash?

(In reply to comment #9)
> I can confirmed this for KDE 4.7.2 (didn't happen with 4.7.1 on my system).
> I am using Gentoo and have Nepomuk and Strigi disabled. Maybe that's causing
> the crash?
This happens very likely, because Gentoo still uses the "dead" Strigi from sf.net instead of libstreamanalyzer and libstreams from projects.kde.org.

We should check whether using libstreamanalyzer and libstreams from projects.kde.org resolves this issue on Gentoo.

See also this comment by Sebastian Trüg: 
http://trueg.wordpress.com/2011/09/22/about-strigi-soprano-virtuoso-clucene-and-libstreamanalyzer/#comment-1550

(In reply to comment #10)
> We should check whether using libstreamanalyzer and libstreams from
> projects.kde.org resolves this issue on Gentoo.
To get the transition to libstreamanalyer/libstreams started on Gentoo, I filed this bug: https://bugs.gentoo.org/show_bug.cgi?id=386057

(In reply to comment #10)
> (In reply to comment #9)
> > I can confirmed this for KDE 4.7.2 (didn't happen with 4.7.1 on my system).
> > I am using Gentoo and have Nepomuk and Strigi disabled. Maybe that's causing
> > the crash?
> This happens very likely, because Gentoo still uses the "dead" Strigi from
> sf.net instead of libstreamanalyzer and libstreams from projects.kde.org.

> We should check whether using libstreamanalyzer and libstreams from
> projects.kde.org resolves this issue on Gentoo.
> 

Well it's happening here with thoses (0.76 release)  so it's probably not enough to revolve this issue.

Confirmed also here with Nepomuk/Strigi disabled. It happens everytime using konqueror when I try to move one pdf file to another dir where another file with the same name is already present.

Commit 23d5ce63 of strigi seems to have fixed this bug. Can anyone confirm that?
See: https://projects.kde.org/projects/kdesupport/strigi/libstreamanalyzer/repository/revisions/23d5ce636b7897dc3f233a5293f3164dac50566d/diff

Can confirm that this happens on KDE 4.6.5 and Dolphin 1.6.1

Fedora 15 x86_64

Removing the Information panel is a work around for me.

I can confirm applying the commit referenced in comment #14 on top of strigi-0.7.6 fixes it for me.

I can also confirm applying the commit referenced in comment #14 applied to strigi-0.7.6 fixes it for me as well.

Fixed on fedora 16

https://admin.fedoraproject.org/updates/search/strigi-0.7.6-3

Newest strigi on Gentoo fixed for me as well (app-misc/strigi-0.7.6-r1).

Fixed in strigi-0.7.6-4.fc16.x86_64

Thanks for the updates, marking as fixed.

http://commits.kde.org/libstreamanalyzer/23d5ce636b7897dc3f233a5293f3164dac50566d