Bug 473801 - crashes while auto-importing new media files
Summary: crashes while auto-importing new media files
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Albums-Engine (show other bugs)
Version: 8.1.0
Platform: Manjaro Linux
: NOR crash
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-08-27 11:54 UTC by Lars
Modified: 2023-09-24 09:06 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 8.2.0
Sentry Crash Report:


Attachments
Backtrace and exiftool log (3.23 KB, application/zip)
2023-08-27 11:54 UTC, Lars
Details
backtrace (87.55 KB, text/plain)
2023-08-27 12:46 UTC, Lars
Details
backtrace 2 (6.26 KB, text/x-log)
2023-08-27 13:31 UTC, Lars
Details
backtrace 8.2.0 (8.00 KB, text/x-log)
2023-08-27 14:05 UTC, Lars
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lars 2023-08-27 11:54:02 UTC
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`
Comment 1 Maik Qualmann 2023-08-27 12:36:11 UTC
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
Comment 2 Lars 2023-08-27 12:46:15 UTC
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.
Comment 3 caulier.gilles 2023-08-27 12:56:21 UTC
it pass in metadata video parser but it's not clear where is located the crash.
Comment 4 Maik Qualmann 2023-08-27 12:59:30 UTC
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
Comment 5 Lars 2023-08-27 13:31:50 UTC
Created attachment 161221 [details]
backtrace 2

as requested, the normal backtrace, created via `bt`.
Comment 6 Maik Qualmann 2023-08-27 13:46:19 UTC
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
Comment 7 Lars 2023-08-27 14:05:35 UTC
Created attachment 161223 [details]
backtrace 8.2.0

Here's the backtrace of digiKam-8.2.0-20230826T081258-x86-64-debug.appimage
Comment 8 Lars 2023-08-27 14:12:12 UTC
(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.
Comment 9 Lars 2023-08-27 14:12:35 UTC
(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!
Comment 10 Maik Qualmann 2023-08-27 14:23:46 UTC
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
Comment 11 Lars 2023-08-27 14:54:35 UTC
(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.
Comment 12 Maik Qualmann 2023-08-27 16:01:16 UTC
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