[Digikam-users] [Feature Request] Catch crashes in third party subsystems and handle them inside digikam

[Nicolas MF]

Sorry to catch up a little late on this. I don't know how much work this
request would mean, or even if it is feasible in this case (I mean proper
handling). Dying gracefully would still be better than silent hara-kiri.

I think it is a great feature request. Of course, things have to get
patched and work, eventually. But as digikam, and most OSS, relies heavily
on other components, this will happen over and over again. "Protecting"
your digikam session against such events is a huge step forward in terms of
robustness.

Nicolas Martinez


On Sat, May 24, 2014 at 6:16 AM, Gilles Caulier <caulier.gilles at gmail.com>
wrote:

> About Sqlite, A upstream patches have been applied in top level, but
> not yet applied to all distribution. See the long story in this bug
> report :
>
> https://bugs.kde.org/show_bug.cgi?id=329697
>
> About Exiv2, library must be patched. It's not yet done.
>
> Gilles Caulier
>
> 2014-05-24 4:49 GMT+02:00 James R. Shipman <JimShip at sbcglobal.net>:
> > Digikam as currently designed is vulnerable to crashes in third party
> > subsystems.  This has showed up strongly with the current problems with
> > sqlite and exiv2 where digikam simply dies every time one of its
> subsystem
> > crashes.
> >
> > I would suggest that a better way would be to catch these crash events
> and
> > either handle them (for example skip a file that caused exiv2 to crash)
> or
> > at least to die gracefully.
> >
> > Not doing this causes digikam to suffer in its reputation and in the
> worst
> > case to make it unusable.  Right now when I start digikam and just let
> it be
> > idle, then a few minutes later it simply disappears. Crashing while
> scanning
> > metadata in the background.  I have been trying to filter out the
> offending
> > files (*.MTS files in my case), but I have to be fast because while I'm
> > trying to change digikam settings (filter out mts type) it will still
> crash
> > causing me to have to start all over.  This is really bad behavior.
> >
> > Jim Shipman
> > _______________________________________________
> > Digikam-users mailing list
> > Digikam-users at kde.org
> > https://mail.kde.org/mailman/listinfo/digikam-users
> _______________________________________________
> Digikam-users mailing list
> Digikam-users at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20140603/aae82cb2/attachment.html>