Exiv2

Nothing can be done about this. DigiKam has to use an interrupt handler to catch this situation.

Of course it's a bug. Try Exiv2 CLI tool with corrupted CR2 file, and lib crash.

digiKam already has the C++ exception handler everywhere to wrap Exiv2 dysfunctions. This is not a DK bug, but an Exiv2 one...

[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]$

I'm neither involved in digikam or exiv and I'm not an expert of dealing with exception but from my point of view this is a memory fault signal and not a standard c++ exception.

Natively it seems not possible to catch that signal by a try/catch mechanism unless maybe some compilation flags. For instance it is possible to compile with -fnon-exception-call with gcc which allows to throw exception inside a signal handler.

I read this and try to use it on exiv2 cli : http://angasule.blogspot.fr/2011/09/catching-null-pointer-exceptions-with.html

If I modify exiv2.cpp this way

#include <signal.h>

static void handler(int sig, siginfo_t *dont_care, void *dont_care_either) {
throw(Exiv2::BasicError<char>(-1));
}

int main(int argc, char* const argv[]) {
…
struct sigaction sa;

memset(&sa, 0, sizeof(sa));
  sigemptyset(&sa.sa_mask);

sa.sa_flags     = SA_NODEFER;
  sa.sa_sigaction = handler;

sigaction(SIGSEGV, &sa, NULL); /*  ignore whether it works or not */ 
…
}

I get this result :

$ ../bin/exiv2 ~/Dropbox/BugDigikamRaw/crw_3888.crw
Exiv2 exception in print action for file /home/thm/Dropbox/BugDigikamRaw/crw_3888.crw:
Error -1: arg2=%2, arg3=%3, arg1=%1.

This time the signal is caught and threw back to the application.

I don't know the impact of this solution and if it is the right one (for portability reason).

Nicolas

Ah, your determination to make me fix this has prevailed. I'll fix this tonight.

I think we're done with this. The article here is interesting http://angasule.blogspot.co.uk/2011/09/catching-null-pointer-exceptions-with.html Perhaps Gilles/DigiKam should consider adding a null pointer exception handler.