| Summary: | Some pictures make digiKam crash (sample included) | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Michiel de Bruijne <m.debruijne> |
| Component: | Metadata-Engine | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | ahuggel, caulier.gilles |
| Priority: | NOR | ||
| Version: | 0.9.0 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 0.9.0 | |
| Sentry Crash Report: | |||
| Attachments: | Testfile to reproduce the crash in digiKam | ||
|
Description
Michiel de Bruijne
2006-08-18 03:30:54 UTC
Created attachment 17408 [details]
Testfile to reproduce the crash in digiKam
Michiel,
I can reproduce the problem. I use Exiv2 library implementation from svn and an assertion fault is generarted by Exiv2 in Jpeg image parser just at digiKam startup if your test image have been put in digiKam library path.
Just for information, witch sofware have generated this jpeg image ? Have you included IPTC informations into ?
Andreas, see below the gdb backtrace:
(gdb) run
Starting program: /opt/kde3/bin/digikam
[Thread debugging using libthread_db enabled]
[New Thread -1240406352 (LWP 5003)]
[New Thread -1243260000 (LWP 5007)]
[Thread -1243260000 (LWP 5007) exited]
[New Thread -1251652704 (LWP 5008)]
[Thread -1251652704 (LWP 5008) exited]
digikam: ScanLib: Finding non-existing Albums: 48 ms
digikam: jpgimage.cpp:317: virtual void Exiv2::JpegBase::readMetadata(): l'assertion « sizeIptc » a échoué.
Program received signal SIGABRT, Aborted.
[Switching to Thread -1240406352 (LWP 5003)]
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb613f7d0 in raise () from /lib/libc.so.6
#2 0xb6140ea3 in abort () from /lib/libc.so.6
#3 0xb613901b in __assert_fail () from /lib/libc.so.6
#4 0xb78cf331 in Exiv2::JpegBase::readMetadata (this=0x8136078)
at jpgimage.cpp:317
#5 0xb7e4f05d in Digikam::DMetaLoader::loadWithExiv2 (this=0xbfa8f260,
filePath=@0xbfa8f2fc) at dmetaloader.cpp:83
#6 0xb7e4a4e8 in Digikam::JPEGMetaLoader::load (this=0xbfa8f260,
filePath=@0xbfa8f2fc) at jpegmetaloader.cpp:35
#7 0xb7e1eab9 in Digikam::DMetadata::load (this=0xbfa8f2f8,
filePath=@0xbfa8f2fc, ff=Digikam::DImg::NONE) at dmetadata.cpp:235
#8 0xb7e1fb10 in DMetadata (this=0xbfa8f2f8, filePath=@0xbfa8f2fc,
ff=Digikam::DImg::NONE) at dmetadata.cpp:70
#9 0xb7cb10e9 in Digikam::ScanLib::storeItemInDatabase (this=0xbfa8f658,
albumURL=@0xbfa8f398, filename=@0xbfa8f3e4, albumID=4) at scanlib.cpp:390
#10 0xb7cb1653 in Digikam::ScanLib::allFiles (this=0xbfa8f658,
directory=@0xbfa8f4f0) at scanlib.cpp:350
#11 0xb7cb1768 in Digikam::ScanLib::allFiles (this=0xbfa8f658,
directory=@0xbfa8f590) at scanlib.cpp:355
#12 0xb7cb2338 in Digikam::ScanLib::findMissingItems (this=0xbfa8f658)
at scanlib.cpp:191
#13 0xb7cb28c1 in Digikam::ScanLib::startScan (this=0xbfa8f658)
Gilles Caulier
Hi Gilles, My friend doesn't own a camera. I think he downloaded the picture from the internet so unfortunately I don't know witch sofware have generated this jpeg image. I/he hasn't changed IPTC informations in the picture. I'm sorry I can't give you more information. Regards, Michiel. Thanks for reporting this problem. Pls try the latest Exiv2 revision from SVN. I changed the assertion to a test, which fixes the problem for me. (The image contains multiple Photoshop IPTC IRBs, some are empty and exiv2 doesn't like that.) This is an interesting picture. It contains all sorts of metadata. -ahu. Yes this pictures is very interressing. It have been generated by Photoshop CS from Mac... With current Exiv2 from svn, digiKam do not crash now. I can close this file... Gilles Andreas, Perhaps to parse indeep this file from photoshop, we can find a solution about B.K.O #130525 to store IPTC data over than 64Kb in JPEG ? Gilles Hi Guys, Thanks for working on this bug! Let's hope a new version of Exiv2 will be released soon so the changes are pushed to the distro's and everybody have a noncrashing digiKam 0.9.0. Do you have a link to svn webinterface or a diff for this change. Can it be applied against Exiv2 0.10? If we need to wait a fair amount of time for the next version of Exiv2 then I can send this patch/diff (and patches for the ebuild) to the Gentoo developers so at least the Gentoo users wont have this problem anymore. Thanks! Regards, Michiel. Michiel, You have right. The diff to fix this bug is very simple and I think that it can be applied against 0.10.0 release. look here: http://dev.robotbattle.com/~cvsuser/cgi-bin/ns_viewcvs.cgi/exiv2/trunk/src/jpgimage.cpp?rev=864&view=diff&r1=864&r2=863&p1=trunk/src/jpgimage.cpp&p2=/trunk/src/jpgimage.cpp Gilles Caulier I can confirm that the diff works perfectly. Thanks! For the Gentoo users; I have created a bugreport with patches for this problem (http://bugs.gentoo.org/show_bug.cgi?id=144347). Thanks to Stefan Briesenick the patch is applied in the main Gentoo tree. Gentoo users wont have this problem anymore. |