https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #28 from Stefan S <stefan.szeke...@gmail.com> --- (In reply to caulier.gilles from comment #27) > The debug stage under OSX hurt me. It's definitively too much complicated... > > As Maik, said, the cardh is located in DMetadata::load() interface which > call Exiv2 libary API to handle file metadata. It's know that Exiv2 is not > stble enough everywhere... but i normally wrapped all Exiv2 call with C++ > exception and protected all Exiv2 calls with Mutex to be thread safe. I > tested myself with unit test to see if Exiv2 support separated thread > operations, and it's not the case. I reported this problem to Exiv2 team, > but making thread safe API is delayed to next release (even if this point is > very important for DK, as all the multithreaded inside...) > > So i suspect a crash due to a cases where Exiv2 code is not protected by C++ > exceptions handling (there still plenty of places in source code). > > To resolve you problem, you need to found which image crash DK while > parsing, try to reproduce the crash with Exiv2 CLI tool, and report the > problem to Exiv2 Github bugzilla. > > Gilles Caulier Can you provide me with a debug build log for all relevant files accessed by digiKam that could cause this crash? I can just run that from scratch, after i delete the current database, and the last line in the log should contain the file in question that crashes the app. -- You are receiving this mail because: You are watching all bug changes.
