Bug 220322

Summary: crash when reading nef data: Warning: Exif tag Exif.NikonPreview.JPEGInterchangeFormatLength not encoded
Product: [Applications] digikam Reporter: jdanne <jdanne>
Component: Metadata-RawAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: crash CC: ahuggel, caulier.gilles, marcel.wiesweg
Priority: NOR    
Version: 0.10.0   
Target Milestone: ---   
Platform: Unlisted Binaries   
OS: Linux   
Latest Commit: Version Fixed In: 7.0.0
Attachments: Obviously this file did crash digikam.

Description jdanne 2009-12-27 22:52:01 UTC
Application that crashed: digikam
Version of the application: 0.10.0
KDE Version: 4.3.1 (KDE 4.3.1) "release 6"
Qt Version: 4.5.3
Operating System: Linux 2.6.31.5-0.1-desktop x86_64
Distribution: "openSUSE 11.2 (x86_64)"

What I was doing when the application crashed:
digikam crashes during startup when scanning the directories.

I suspect that it  has problems to handle the Nikon NEF format:

...
Warning: Exif IFD NikonPreview not encoded
Warning: Exif tag Exif.NikonPreview.JPEGInterchangeFormatLength not encoded
Warning: Exif IFD NikonPreview not encoded
Warning: Exif tag Exif.NikonPreview.JPEGInterchangeFormatLength not encoded
Warning: Exif IFD NikonPreview not encoded
Warning: Exif tag Exif.NikonPreview.JPEGInterchangeFormatLength not encoded
Warning: Exif IFD NikonPreview not encoded
Warning: Exif tag Exif.NikonPreview.JPEGInterchangeFormatLength not encoded
Warning: Exif IFD NikonPreview not encoded
Warning: Exif tag Exif.NikonPreview.JPEGInterchangeFormatLength not encoded
Warning: Exif IFD NikonPreview not encoded
Warning: Exif tag Exif.NikonPreview.JPEGInterchangeFormatLength not encoded
Warning: Exif IFD NikonPreview not encoded
KCrash: Application 'digikam' crashing...
sock_file=/home/jdanne/.kde4/socket-linux-meqw/kdeinit4__0
digikam: Fatal IO error: client killed

[1]+  Angehalten              digikam
jd

 -- Backtrace:
Application: digiKam (digikam), signal: Segmentation fault
[Current thread is 1 (Thread 0x7fd313ae9750 (LWP 9615))]

Thread 2 (Thread 0x7fd300622910 (LWP 9616)):
[KCrash Handler]
#5  0x00007fd30c07cfa9 in ?? () from /usr/lib64/libexiv2.so.5
#6  0x00007fd30c07fc0a in ?? () from /usr/lib64/libexiv2.so.5
#7  0x00007fd30c07c0c0 in Exiv2::PngImage::readMetadata() () from /usr/lib64/libexiv2.so.5
#8  0x00007fd3124772ba in KExiv2Iface::KExiv2::load(QString const&) const () from /usr/lib64/libkexiv2.so.7
#9  0x00007fd31101d5b9 in Digikam::DMetadata::load(QString const&) const () from /usr/lib64/libdigikamcore.so.1
#10 0x00007fd310c7c071 in Digikam::ImageScanner::loadFromDisk() () from /usr/lib64/libdigikamdatabase.so.1
#11 0x00007fd310c82058 in Digikam::ImageScanner::newFile(int) () from /usr/lib64/libdigikamdatabase.so.1
#12 0x00007fd310c74f2b in Digikam::CollectionScanner::scanNewFile(QFileInfo const&, int) () from /usr/lib64/libdigikamdatabase.so.1
#13 0x00007fd310c762ba in Digikam::CollectionScanner::scanAlbum(Digikam::CollectionLocation const&, QString const&) () from /usr/lib64/libdigikamdatabase.so.1
#14 0x00007fd310c761db in Digikam::CollectionScanner::scanAlbum(Digikam::CollectionLocation const&, QString const&) () from /usr/lib64/libdigikamdatabase.so.1
#15 0x00007fd310c761db in Digikam::CollectionScanner::scanAlbum(Digikam::CollectionLocation const&, QString const&) () from /usr/lib64/libdigikamdatabase.so.1
#16 0x00007fd310c76cb7 in Digikam::CollectionScanner::scanAlbumRoot(Digikam::CollectionLocation const&) () from /usr/lib64/libdigikamdatabase.so.1
#17 0x00007fd310c76f87 in Digikam::CollectionScanner::completeScan() () from /usr/lib64/libdigikamdatabase.so.1
#18 0x00000000006438b3 in ?? ()
#19 0x00007fd30e281485 in ?? () from /usr/lib64/libQtCore.so.4
#20 0x00007fd30d53865d in start_thread () from /lib64/libpthread.so.0
#21 0x00007fd30d81f14d in clone () from /lib64/libc.so.6
#22 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7fd313ae9750 (LWP 9615)):
#0  0x00007fd30d53d049 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007fd30e28253b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib64/libQtCore.so.4
#2  0x00007fd30e281524 in QThread::wait(unsigned long) () from /usr/lib64/libQtCore.so.4
#3  0x0000000000643617 in ?? ()
#4  0x000000000064708b in ?? ()
#5  0x0000000000647227 in ?? ()
#6  0x00007fd30d783065 in ?? () from /lib64/libc.so.6
#7  0x00007fd30d7830b5 in exit () from /lib64/libc.so.6
#8  0x00007fd30ef3c628 in ?? () from /usr/lib64/libQtGui.so.4
#9  0x00007fd30fd222b8 in KApplication::xioErrhandler(_XDisplay*) () from /usr/lib64/libkdeui.so.5
#10 0x00007fd30c6e42be in _XIOError () from /usr/lib64/libX11.so.6
#11 0x00007fd30c6ebc95 in ?? () from /usr/lib64/libX11.so.6
#12 0x00007fd30c6ec547 in _XEventsQueued () from /usr/lib64/libX11.so.6
#13 0x00007fd30c6d524b in XEventsQueued () from /usr/lib64/libX11.so.6
#14 0x00007fd30ef744dc in ?? () from /usr/lib64/libQtGui.so.4
#15 0x00007fd308168cba in g_main_context_check () from /usr/lib64/libglib-2.0.so.0
#16 0x00007fd3081694a0 in ?? () from /usr/lib64/libglib-2.0.so.0
#17 0x00007fd3081698d0 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#18 0x00007fd30e38f3a3 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4
#19 0x00007fd30ef7431e in ?? () from /usr/lib64/libQtGui.so.4
#20 0x00007fd30e365712 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4
#21 0x00007fd30e365ae4 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4
#22 0x0000000000644ae2 in ?? ()
#23 0x0000000000608cb3 in ?? ()
#24 0x00000000006690ea in ?? ()
#25 0x00007fd30d76ca7d in __libc_start_main () from /lib64/libc.so.6
#26 0x0000000000458849 in _start ()

This bug may be a duplicate of or related to bug 218726

Reported using DrKonqi
Comment 1 caulier.gilles 2009-12-27 22:56:42 UTC
Exiv2 library relevant.

1/ Use last digiKam 1.0.0
2/ use last Exiv2 0.18.2
3/ update libkexiv2 and kipi-plugins.
4/ Look in Help/Comopnents Info if all is fine with versions.
5/ try again.
6/ If it crash again, try to find the image relevant and give us a link to download and test.

Gilles Caulier
Comment 2 jdanne 2009-12-27 23:40:08 UTC
   Hello Caulier,

obviously the attached  file caused digkam to crash.

Best regards
   Joerg


Am Sonntag, 27. Dezember 2009 22:56:43 schrieb Gilles Caulier:
> https://bugs.kde.org/show_bug.cgi?id=220322
> 
> 
> Gilles Caulier <caulier.gilles@gmail.com> changed:
> 
>            What    |Removed                     |Added
> ---------------------------------------------------------------------------
> - CC|                            |ahuggel@gmx.net
>           Component|general                     |Metadata
>             Version|unspecified                 |0.10.0
> 
> 
> 
> 
> --- Comment #1 from Gilles Caulier <caulier gilles gmail com>  2009-12-27
>  22:56:42 --- Exiv2 library relevant.
> 
> 1/ Use last digiKam 1.0.0
> 2/ use last Exiv2 0.18.2
> 3/ update libkexiv2 and kipi-plugins.
> 4/ Look in Help/Comopnents Info if all is fine with versions.
> 5/ try again.
> 6/ If it crash again, try to find the image relevant and give us a link to
> download and test.
> 
> Gilles Caulier
>
Comment 3 Mark Purcell 2009-12-28 00:27:57 UTC
Joerg,

Could you please attach the file.  It hasn't come through on the bug tracking system.

Thanks,
Mark
Comment 4 jdanne 2009-12-28 12:29:38 UTC
Created attachment 39398 [details]
Obviously this file did crash digikam.
Comment 5 Marcel Wiesweg 2009-12-28 13:13:28 UTC
Crash is clearly reproducable with exiv2 command line utility and current trunk. It's a PNG file btw.
Filed report at 
http://dev.exiv2.org/issues/show/664
please watch progress there.
Comment 6 Mark Purcell 2009-12-28 14:01:33 UTC
On Monday 28 December 2009 23:13:30 Marcel Wiesweg wrote:
> Crash is clearly reproducable with exiv2 command line utility and current
> trunk. It's a PNG file btw.
> Filed report at 
> http://dev.exiv2.org/issues/show/664
> please watch progress there.

This is terrible!

Whilst I understand the core issue with exiv2, the inability to handle this 
error condition in multiple KDE applications is very severe.

This runs contrary to the Robustness Principle.[1]

Imagine if this image was placed on a prominent web site, such as google, or 
even a series of anti FOSS sites.

Mark

[1] http://en.wikipedia.org/wiki/Robustness_principle
Comment 7 Marcel Wiesweg 2009-12-29 15:20:08 UTC
Yes it's true crashes should never occur.
The only workaround would be to move actual file access into a separate process and watch for crashes. Amarok does or did that for it's scanning process. It's a huge work and overhead.

In our experience it's only the odd photo here and there leading to exiv2 crashes. Exiv2's development pace is fast. That means  occasionally a crash will slip in. It's the same in every project. But it's very well maintained and communication is excellent, see that the issue is fixed after a day.
Comment 8 caulier.gilles 2019-12-23 17:41:13 UTC
Not reproducible with digiKam 7.0.0-beta1.