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

[James R. Shipman]

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
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

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 <[hidden email]>:

> 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
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

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 <[hidden email]> 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 <[hidden email]>:

> 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
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Peter Albrecht]

Hello mailing-list,

I totally agree with Nicolas and Jim: Error-management is
difficult, but enhances software stability a lot.
Of course someone must be found, doing this job. ;)

Maybe one of you, Jim or Nicolas, could file a feature
request at https://bugs.kde.org/ and post the link in this list.

Then people could start voting for it. And it will remain in
TODO-lists longer than just three mails in the mailing list.

Regards,
        Peter

On 03.06.2014 07:11, Nicolas MF wrote:

> 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
>>
>> 2014-05-24 4:49 GMT+02:00 James R. Shipman <[hidden email]>:
>>> 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
>>> [hidden email]
>>> https://mail.kde.org/mailman/listinfo/digikam-users
>> _______________________________________________
>> Digikam-users mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
>>
>
>
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users