| Summary: | broken png image present in albums folder causes digikam to crash when starting | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Michał Kosmulski <michal> |
| Component: | Metadata-Engine | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | caulier.gilles, marcel.wiesweg |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Slackware | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 0.9.4 | |
| Sentry Crash Report: | |||
|
Description
Michał Kosmulski
2008-01-04 20:13:11 UTC
Hmm, my image is 2.7 MB in size and the bug system doesn't allow me to upload files larger than 1 MB. Can I upload the file some place else? Crash appears in Exiv2, not digiKam. Gilles Caulier Michał, Can you send the image to me directly: a h u g g e l AT g m x DOT n e t Thanks, Andreas Thanks for the image. This is Exiv2 bug #537 (http://dev.robotbattle.com/bugs/view.php?id=537), it is fixed in SVN rev. 1362. Andreas Accordingly with Exiv2 bugzilla : http://dev.robotbattle.com/bugs/view.php?id=537 ... this bug have been fixed by Andreas in current implementation of Exiv2 (future 0.16 release) Gilles Still I think that Michal's point
> However, digikam certainly shouldn't crash - it should display an error message
> and just show a placeholder instead of thumbnail for that single image.
is valid and important.
Digikam should behave better in such a situation.
Is this technically possible?
Arnd, The crash is indeep in libexiv2. If something is wrong in Exiv2 implementation, the host crash too. Currently, i think than Andreas as used C++ exception to prevent a crash internally. libkexiv2 take a care about exception and in this case just an error will be reported to host. Andreas, if i'm wrong, please fix me... Gilles Gilles, Yes, exiv2 throws an exception when it encounters a problem that it can't handle. But in case of a bug, i.e., if something unexpected happens, it may just crash. Some applications show a "bomb-screen" in such situations, which usually says something like "We're sorry the application has encountered a problem and needs to be closed". At least it doesn't just disappear, although the net effect is not so different. I think KDE apps do that. What about digiKam? Do external libraries need to behave in a certain way to enable an application to support this also for crashes of the library? Andreas Andreas, Well, i have no idea how to make this behaviors in digiKam/libkexiv2 when a crash appears in a shared library... Marcel, are you any ideas about this subject ? Gilles "Dr.Konqi" appears regardless if the crash appears in a shared library or in the main application - if you look at our binary layout, I would guess that 98% of the code is in shared libraries anyway (from libc over Qt and kdelibs to libdigikam). "Not crashing" is unfortunately not possible. There is no difference from which binary object the crash comes, it is all code that the process executes, which is then killed by the OS. Amarok has gone so far as to source out collection scanning to a dedicated process, which may then crash. This is a solution, but so far I think we do not need it so much because 1) libexiv2 crashes are rare as it appears to me 2) libexiv2 is very well maintained Andreas, don't know if you have heard of this toy: http://sam.zoy.org/zzuf/ |