Bug 359949

Summary:	Bad canon raw file makes digikam to crash at startup
Product:	[Applications] digikam	Reporter:	Nicolas T <nospam1>
Component:	Metadata-Raw	Assignee:	Digikam Developers <digikam-bugs-null>
Status:	RESOLVED FIXED
Severity:	crash	CC:	caulier.gilles
Priority:	NOR
Version:	3.5.0
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed In:	7.0.0
Sentry Crash Report:

Description Nicolas T 2016-03-01 12:03:55 UTC

Here is the story.

Digikam first crashed while moving files inside digikam. Source and destination were on two different partitions. This ended up with a partially (i suppose) copied file on the destination partition.

I have to mention that the file is canon crw raw file.

Now each time digikam is restarted it seems to try to process the partially copied file and then crashes. 

Here is a link to the original file and the partially copied file that makes my digikam version crash : https://www.dropbox.com/sh/jwx0lw6gtae5y2p/AACGPr-dddNdFisFMl-5WqEza?dl=0

While debug package of digikam and libkipi have been installed, I'm unable to retrieve debug information. Maybe this bug has already been corrected in a recent version. 

Other tools behaviour regarding this file: 
 - aftershot 1 and 2 as well as rawtherapy don't recognize the partially copied file as a valid one and skip it
 - darktable crashes

Reproducible: Always

Steps to Reproduce:
1.open the corrupted file from showphoto or digikam
2.
3.

Actual Results:  
The software crashes

Expected Results:  
file should be ignored and the application shall survive. 

I'm on Ubuntu 14.04. I use not to update every packages :
 - security update are done;
 - only applications that matters to me are updated.


Displayed error:
Application: digiKam (digikam), signal: Segmentation fault

Please feel free to contact me if I can be of any help.

Comment 1 caulier.gilles 2016-03-02 06:04:05 UTC

Reproducible with 5.0.0.

The crash is in Exiv2 shared library :

Thread 1 (Thread 0x7f54e39bda40 (LWP 10870)):
[KCrash Handler]
#6  0x00007f55098f1718 in Exiv2::getUShort(unsigned char const*, Exiv2::ByteOrder) (buf=buf@entry=0x7f55d4019019 <error: Cannot access memory at address 0x7f55d4019019>, byteOrder=byteOrder@entry=Exiv2::littleEndian) at types.cpp:236
#7  0x00007f5509855fc4 in Exiv2::Internal::CiffDirectory::readDirectory(unsigned char const*, unsigned int, Exiv2::ByteOrder) (this=0x1d89e90, pData=0x7f54d401901a "", size=1277926, byteOrder=Exiv2::littleEndian) at crwimage.cpp:452
#8  0x00007f5509856327 in Exiv2::Internal::CiffHeader::read(unsigned char const*, unsigned int) (this=this@entry=0x1d89e60, pData=pData@entry=0x7f54d4019000 "II\032", size=size@entry=1277952) at crwimage.cpp:391
#9  0x00007f5509856481 in Exiv2::CrwParser::decode(Exiv2::CrwImage*, unsigned char const*, unsigned int) (pCrwImage=pCrwImage@entry=0x1d89d90, pData=0x7f54d4019000 "II\032", size=size@entry=1277952) at crwimage.cpp:177
#10 0x00007f55098566cd in Exiv2::CrwImage::readMetadata() (this=0x1d89d90) at crwimage.cpp:134
#11 0x00007f550cf59e75 in Digikam::MetaEngine::load(QString const&) const (this=0x7ffc08993850, filePath=...) at /home/gilles/Devel/5.x/core/libs/dmetadata/metaengine.cpp:283
#12 0x00007f550cf95237 in Digikam::DMetadata::load(QString const&) const (this=0x7ffc08993850, filePath=...) at /home/gilles/Devel/5.x/core/libs/dmetadata/dmetadata.cpp:100
#13 0x0000000000453021 in ShowFoto::ShowFoto::openUrls(QList<QUrl> const&) (this=0x16fcba0, urls=...) at /home/gilles/Devel/5.x/core/showfoto/main/showfoto.cpp:526
#14 0x0000000000457b0a in ShowFoto::ShowFoto::slotDroppedUrls(QList<QUrl> const&) (this=0x16fcba0, droppedUrls=...) at /home/gilles/Devel/5.x/core/showfoto/main/showfoto.cpp:1282
#15 0x0000000000450107 in ShowFoto::ShowFoto::ShowFoto(QList<QUrl> const&) (this=0x16fcba0, urlList=..., __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at /home/gilles/Devel/5.x/core/showfoto/main/showfoto.cpp:202
#16 0x000000000044e816 in main(int, char**) (argc=2, argv=0x7ffc08993f58) at /home/gilles/Devel/5.x/core/showfoto/main/main.cpp:86

In fact digiKam handle all exception from Exiv2 already, since a long. Exiv2 in case of corrupted file must take a care about this problematic case, and generate a C++ exception instead to crash.

It's also reproducible directly with Exiv2 CLI tool :

[gilles@localhost BugDigikamRaw]$ exiv2 --version
exiv2 0.25 001900 (64 bit build)
Copyright (C) 2004-2015 Andreas Huggel.

This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public
License along with this program; if not, write to the Free
Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
Boston, MA 02110-1301 USA
[gilles@localhost BugDigikamRaw]$ exiv2 -v crw_3888.crw 
File 1/1: crw_3888.crw
Segmentation fault (core dumped)
[gilles@localhost BugDigikamRaw]$ 

Report this problem as UPSTREAM to Exiv2 bugzilla with link to CR2 files to download.

Gilles Caulier

Comment 2 Nicolas T 2016-03-02 09:06:54 UTC

I created an issue in exiv2 bug tracking system : http://dev.exiv2.org/issues/1164

Thank you for helping me out.

Nicolas THOMASSON

Comment 3 caulier.gilles 2019-12-23 17:51:06 UTC

Not reproducible with digiKam 7.0.0-beta1.