| Summary: | crashes while auto-importing new media files | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Lars <lars+kde> |
| Component: | Albums-Engine | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | caulier.gilles, metzpinguin |
| Priority: | NOR | ||
| Version: | 8.1.0 | ||
| Target Milestone: | --- | ||
| Platform: | Manjaro | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/graphics/digikam/-/commit/8a7ee594fbee5a1c1bcd147e5d023802d258af86 | Version Fixed In: | 8.2.0 |
| Sentry Crash Report: | |||
| Attachments: |
Backtrace and exiftool log
backtrace backtrace 2 backtrace 8.2.0 |
||
Your digiKam log does not show any video files. Here are unreadable JPEG files. Presumably encrypted as they are in a folder called "cryptdata". Exiv2 produces error messages, it will probably crash as well. The ExifTool is unlikely to produce the crash. Please create a backtrace with GDB, don't forget the "bt" + enter after the crash. Maik Created attachment 161215 [details]
backtrace
added the log output instead of the backtrace, sorry. Here's the backtrace of the same run.
Despite being on an encrypted partition, the filesystem is mounted unencrypted, so that is not the issue.
it pass in metadata video parser but it's not clear where is located the crash. However, the log clearly shows that your jpeg files cannot be read, and no thumbnails can be created either. I don't see the crash point in your backtrace. Please create a simple GBD log, only outputting "bt" at the end. Maik Created attachment 161221 [details]
backtrace 2
as requested, the normal backtrace, created via `bt`.
At this point we're adding an album, but there's no apparent crash. This part is also in the first backtrace. In digiKam-8.2.0 there is a change in removing albums to have full read/write protection of the album child cache. So it would be interesting if you would test our digiKam-8.2.0 AppImage. https://files.kde.org/digikam/digiKam-8.2.0-20230826T081258-x86-64.appimage Please provide the video file, send it to my mail address. Maik Created attachment 161223 [details]
backtrace 8.2.0
Here's the backtrace of digiKam-8.2.0-20230826T081258-x86-64-debug.appimage
(In reply to Lars from comment #7) > Created attachment 161223 [details] > backtrace 8.2.0 > > Here's the backtrace of digiKam-8.2.0-20230826T081258-x86-64-debug.appimage Just noticed: I just reran the binary again and this time it did _not_ crash. (In reply to Maik Qualmann from comment #6) > At this point we're adding an album, but there's no apparent crash. This > part is also in the first backtrace. In digiKam-8.2.0 there is a change in > removing albums to have full read/write protection of the album child cache. > So it would be interesting if you would test our digiKam-8.2.0 AppImage. > > https://files.kde.org/digikam/digiKam-8.2.0-20230826T081258-x86-64.appimage > > Please provide the video file, send it to my mail address. > > Maik done - thanks again for helping! There isn't really a crash, I see that it's at a Qt_ASSERT stop. They run Qt in debug mode or an environment variable is set so that every Qt_ASSERT leads to an abort. According to the Qt Doc, m_childCache.value(row, nullptr); would be valid. I suspect, but that if row is out of range Qt will do a Qt_ASSERT. I will take a look. Maik (In reply to Maik Qualmann from comment #10) > There isn't really a crash, I see that it's at a Qt_ASSERT stop. They run Qt > in debug mode or an environment variable is set so that every Qt_ASSERT > leads to an abort. > According to the Qt Doc, m_childCache.value(row, nullptr); would be valid. I > suspect, but that if row is out of range Qt will do a Qt_ASSERT. I will take > a look. > > Maik please note that I used the -debug.appimage on the 8.2.0, just in case that explains this behavior. Git commit 8a7ee594fbee5a1c1bcd147e5d023802d258af86 by Maik Qualmann. Committed on 27/08/2023 at 17:58. Pushed by mqualmann into branch 'master'. fix crash in album child cache when Qt is build with debugging assertions Related: bug 473110 FIXED-IN: 8.2.0 M +2 -1 NEWS M +6 -1 core/libs/album/engine/album.cpp https://invent.kde.org/graphics/digikam/-/commit/8a7ee594fbee5a1c1bcd147e5d023802d258af86 |
Created attachment 161209 [details] Backtrace and exiftool log SUMMARY digikam cashes while a background job is looking for new entries. It seems stumbles over a videofile while loading the EXIF metadata. This happens reproducibly. STEPS TO REPRODUCE - I can provide the offending videofile, but not in this bug tracking system (as its more than 4mb in size). SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro rolling release (64bit, Gnome 44.3) Qt Version: 5.15.10 ADDITIONAL INFORMATION If if call exiftool in the commandline on the file in question, I do get an output with exitcode 0: `exiftool -TagsFromFile /mnt/cryptdata/Bilder/2023/08/19/p1050671.mp4 -all -o -.exv`