[Digikam-devel] [Bug 273765] replacing pgf files with an open digikam lead to reproducible crash

Francesco Riosa francesco+kde at pnpitalia.it
Tue May 24 20:22:55 BST 2011


--- Comment #5 from Francesco Riosa <francesco+kde pnpitalia it>  2011-05-24 21:22:48 ---
ok, after a lot of learning of gdb, and some reading on signals and exceptions
and also pgf specs:

There are two parts of this bug:
The first is a bad pgf file generated from the batch queque manager, I would
consider this a non issue, since there was intervention from the shell while
digikam was still running

The second is a unpleasant crash when a corrupted file is loaded:

The file is corrupted (redoing it give a correct one #1), _dsc4243.pgf headers
are correct #2 so it pass all initial checks and then if asserts are enabled it
ASSERT(sigPos + runlen <= BufferSize);
in Decoder.cpp:725 CDecoder::RLDSigsAndSigns(...)

For this example it's impossible to catch the problem early as it's done for
other things in pgfloader.cpp

Seem to me that the only solutions available are:
- rewrite libpgf to handle exceptions (slowing it down) and to fit better in a
qt env (no no no)
- fork an external process to read te image (like plasma does with plasmoids)
which can be inefficient at best
- register a SIGINT catcher
- close as wont fix

any ideas?

Note to self: converting .nef in batch resize+pgf does not give byte exact
files if run twice there are usually at least 3 or 4 bytes that differ

#1 http://xn--wtf-xs0a.ws/Bug273765/_dsc4243_ok.pgf
#2 I've created a structure for okteta available here:

Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

More information about the Digikam-devel mailing list