I have isolated a certain mp4-file that crashes Digikam while indexing the file. Reproducible: Always Steps to Reproduce: Paste file into a digikam album-folder inside digikam. OR Place file in a album folder outside of digikam and start digikam to let it index the file. Actual Results: 1. digikam tries to index the file 2. digikam crashes Expected Results: - I tried to cut the file to see what would happen, cut it all the way down to 5kb and it still crashes. Original file was 29mb, unfortunately I can't publish the full file, but these pieces still triggers the crash http://jkabrams.se/files/digikam-crash/video_crashing_digikam_5k.mp4 http://jkabrams.se/files/digikam-crash/video_crashing_digikam_500k.mp4 http://jkabrams.se/files/digikam-crash/video_crashing_digikam_2m.mp4 Console output http://pastebin.com/6ZwH6hs7
Created attachment 85801 [details] The offending video Sorry about my links not working, (something wrong with my server mimetype settings). Here's the 2mb version of the file.
Created attachment 85802 [details] Offending video 5kb And the 5kb version.
run digiKam in a console through GDB to get a backtrace to hack, as explained here : http://www.digikam.org/contrib Gilles Caulier
Created attachment 85807 [details] Stracktrace, but without debug symbols (In reply to comment #3) > run digiKam in a console through GDB to get a backtrace to hack, as > explained here : > > http://www.digikam.org/contrib > > Gilles Caulier It's not reproducible then? Guess I'll have to figure out how to build it with debugging symbols for Arch then. Would it be enough to rebuild only digikam itself with debugging symbols or will I also need to rebuild the dependencies? Here is the stack trace I have now, is it of any use without the debug symbols?
From your trace it crash in Exiv2 shared lib when video file is parsed: Thread 24 (Thread 0x7fa970e9e700 (LWP 540)): [KCrash Handler] #5 0x00007fa99830c7d5 in Exiv2::QuickTimeVideo::movieHeaderDecoder(unsigned long) () from /usr/lib/libexiv2.so.13 #6 0x00007fa99830dd9b in Exiv2::QuickTimeVideo::tagDecoder(Exiv2::DataBuf&, unsigned long) () from /usr/lib/libexiv2.so.13 #7 0x00007fa99830e1a0 in Exiv2::QuickTimeVideo::decodeBlock() () from /usr/lib/libexiv2.so.13 #8 0x00007fa99830dd40 in Exiv2::QuickTimeVideo::tagDecoder(Exiv2::DataBuf&, unsigned long) () from /usr/lib/libexiv2.so.13 #9 0x00007fa99830e1a0 in Exiv2::QuickTimeVideo::decodeBlock() () from /usr/lib/libexiv2.so.13 #10 0x00007fa99830e3d5 in Exiv2::QuickTimeVideo::readMetadata() () from /usr/lib/libexiv2.so.13 #11 0x00007fa9a02d1be5 in KExiv2Iface::KExiv2::load(QString const&) const () from /usr/lib/libkexiv2.so.11 Please report this problem to Exiv2 bugzilla. Thanks in advance Gilles Caulier
I have this problem too.
Is there a pointer to where this was resolved upstream? Also, even if exiv2 fails, sucks for digikam to segfault.
*** Bug 343643 has been marked as a duplicate of this bug. ***
*** Bug 345457 has been marked as a duplicate of this bug. ***
*** Bug 352777 has been marked as a duplicate of this bug. ***
With 6.0.0, we have now a FFMpeg low level metadata parser based on libav C API for video files database registration. The Exiv2 video support is not used anymore as this code is buggous and nobody sound motivated in Exiv2 to finalize the code. The original post for this file must be fixed now and video metadata support with ffmpeg must be enough to populate database entries. Gilles Caulier