Bug #1280
crash in Exiv2 shared library when a video file is under construction
100%
Description
Hello,
I started compressing an mp4 file saving the output to the original directory. digiKam detected a change, trigered rescan which in turn called exiv2 (https://cgit.kde.org/digikam.git/tree/libs/dmetadata) and then exiv2 crashed.
I guess Exiv2 code could use some wrap around this situation to prevent a crash. At least, a C++ exception could be generated, not a crash. C++ exception will be catched by digiKam.
More details can be found here:
https://bugs.kde.org/show_bug.cgi?id=376951
Exiv2 0.26-svn
Related issues
History
Updated by Robin Mills over 4 years ago
- Category set to video
- Target version changed from 0.26 to 0.28
Regrettably nothing can be done about this at the moment as I am preparing the v0.26 release.
I agree that the library shouldn't crash and I am aware that the video code requires additional "hardening". The video code should not be compiled into libexiv2. The handling of crashes is an application responsibility and should be handled gracefully by digiKam.
I think digiKam should consider shipping the libexiv2 shared library with their application. To rely on the "platform" provided version of libexiv2 shared library can cause difficulties if the API of the shared exiv2 library is modified. Bundling a copy of libexiv2.dll (on Windows), libexiv2.dylib (on Mac), libexiv2.so (on Linux) is a modest addition to the installer and avoids API issues for users and developers. It also enable digiKam to resolve issues by replacing the share library that is exclusively used by their application. Before I retired, I worked for Adobe for many years and they always ship the appropriate shared libraries with applications to avoid mismatched share library/application issues with shipping products.
Another aspect of this issue is troublesome. It sounds as though one thread of digiKam is building your file and another is trying to parse the same file. There is code no code in Exiv2 to handle an incomplete file. The assumption is that the file is complete and is written to the standard. Perhaps digiKam requires a mutex (or other locking mechanism) to avoid this situation.
Updated by Robin Mills over 4 years ago
- Status changed from New to Closed
- Assignee set to Robin Mills
- Target version changed from 0.28 to 0.26
- % Done changed from 0 to 100
- Estimated time set to 1.00 h
I've linked this issue to #1068 which is the "Video Code Umbrella". I'm hoping a member of Team Exiv2 will volunteer to do some video maintenance in 2017. So this issue will be visible to that effort.
However, on the current description, it sounds impossible to consistently replicate this behaviour and is probably a defect of the digiKam architecture.
Updated by Gilles Caulier over 4 years ago
Robin,
This is not a digiKAm architecture failure. It's a crash from Exiv2 with video file which do not generate a C++ exception. Digikam::DMetadata interface use C++ exception catcher everywhere. If something go wrong in Exiv2, it's must generate an exception. It's not the case currently, and video support failures have been reported a lots of time by digiKam users. This is abnormal...
Gilles Caulier
Updated by Robin Mills over 4 years ago
I strongly disagree with your judgement. A crash cannot be caught by an Exception handler. It is a process wide event.
I am aware that the video code requires considerable work. It was introduced in 2012 by following your recommendation to involve a student from Google Summer of Code. I really like the student who did this work and the student who worked in 2013 on the write code. I want to visit them in India last year. However the legacy of that work has consumed a lot of my time and introduced many issues in the code. You are aware that I am the principal contributor to Exiv2. It's more-or-less an unpaid full time job. I regret that I have not been able to visit the video code and to make it more solid and reliable. In 2014, it was decided to make the video code a compile option. I voted to remove the code.
Gilles: I feel you underestimate the effort that I invest on your behalf. Your lack of judgement has created the current state of things. I am dealing with the mess you created.
Updated by Gilles Caulier over 4 years ago
"...with the mess you created..."
Seriously. I prefer to not respond... (:=(((
You are right : remove video code immediately from Exiv2. You will sleep better i'm sure...
Gilles Caulier
Updated by Robin Mills over 4 years ago
It's too late in the v0.26 project to remove the video code. I hope to get somebody to work on this in v0.27. Their judgement may be to remove it. They may fix it. Time will tell.
I will be leaving the Exiv2 project in December 2017 after 10 years of solid service. I regret that you and I have not formed a better working relationship.