| Summary: | Digikam often freezes when dropping a tag over another to merge them | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | MarcP <iwannaberich> |
| Component: | Tags-Keywords | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | caulier.gilles, iwannaberich, metzpinguin |
| Priority: | NOR | ||
| Version First Reported In: | 7.4.0 | ||
| Target Milestone: | --- | ||
| Platform: | Flatpak | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | 7.4.0 | |
| Sentry Crash Report: | |||
| Attachments: |
console output when running digiKam-7.4.0-20210905T231405-x86-64-debug
console output when running digiKam-7.4.0-20211106T090435-x86-64-debug.appimage with bt |
||
|
Description
MarcP
2021-11-04 18:25:51 UTC
I can't think of any recent change that could lead to this. A log from the terminal when it freezes would be good. Maik I tried it now, tagged 6 pictures with a new tag, and then merging them, and digikam crashed. I ran it using flatpak run org.kde.digikam debug, but I don't see much output on the command line. Do you know how to enter debug mode in flatpak? Created attachment 143215 [details]
console output when running digiKam-7.4.0-20210905T231405-x86-64-debug
I was able to capture the console output when running the latest appimage available, dating from 05/09/2021. I have attached the file. I'm not sure if it will help.
I cannot reproduce any problems with the current GIT version. Exiv2 has many exceptions in your log that may lead to a crash. Digikam::MetaEngine::Private::printExiv2ExceptionError: Cannot get metadata tag title with Exiv2: (Error # 7 : "Invalid tag name or ifdId `BurstSheed', ifdId 115" Maik From which camera are the images that lead to the crash? I found a thread at Exiv2 that "BurstSheed" is a typo and must be called "BurstSpeed". However, this is not relevant for the crash. Maik I am using the same 6 pictures for the tests. Two are scanned pictures, two are from an old phone (Motorola v525), two are from a Sony DSC-W7, and two from a smartphone (Nexus S). I have tried with the stable Digikam 7.3 appimage, and I can confirm that the problem does not happen in that version. Can you please test it with today's AppImage? Maik I just tried (with digiKam-7.4.0-20211106T090435-x86-64-debug.appimage), and digikam still freezes when I try to merge two tags. I have tested the current AppImage here and have merged tags several times, no problems. Tags are written into the images etc. Can you use the debug AppImage and start with the "debug" option, if digiKam freezes, in the terminal interrupt with CTRL+C, look with "bt" where digiKam is, continue with "c" and repeat this 3-4 times and post the log? Maik Created attachment 143286 [details]
console output when running digiKam-7.4.0-20211106T090435-x86-64-debug.appimage with bt
Here's the log including the backtrace. I hope you find something useful.
Maik, It crash in Tags cache from database call, and QtCore. In AppImage, Qt 5.15.2 and new libexiv2 0.27.5 are used. perhaps there is a conflict with a different libQt5 from the system, but, i already tested this case under CentOS where i enabled the modules Qt 5.5 | 5.7 | 5.12, and i never seen this dysfunction... Gilles Yes, I've already seen it, the cause will be this external patch: https://invent.kde.org/graphics/digikam/-/commit/91d6d899bf7663f1746bddfef9303d16ff9543e0 It is a race condition, probably compiler dependent / number of threads etc. We have a read / write lock problem here. I fix it, just have to recompile digiKam because openSUSE has updated a lot. Maik Git commit e1ab779c6a3f5594b656e3ee40955f528d7bdc9c by Maik Qualmann. Committed on 06/11/2021 at 19:34. Pushed by mqualmann into branch 'master'. fix QReadWriteLock race condition in the TagsCache M +36 -29 core/libs/database/tags/tagscache.cpp https://invent.kde.org/graphics/digikam/commit/e1ab779c6a3f5594b656e3ee40955f528d7bdc9c Marc, can you reproduce the problem with the new AppImage? Maik I just tried with today's appimage, and also with the latest flatpak, using the same pictures, and the problem seems to have been solved. Thanks! Thank you for your feedback and for creating the backtraces to localize the problem. Maik |