Created attachment 165224 [details] Test .PNG image created in GIMP, with Exif.Photo.UserComment set to "????" using ExifTool SUMMARY When digiKam attempts to retrieve metadata from an image using Exiv2, if the Exif.Photo.UserComment field for that image contains an emoji (or any other character outside UCS-2, I assume), digiKam crashes. STEPS TO REPRODUCE 1. Select or refresh album folder containing an image with emoji in Exif.Photo.UserComment (also occurs on startup when loading last-viewed album, if that album has said image) Alternatively: 1. Add UserComment to existing image using outside program (ex. Exiftool) 2. Select image in digiKam OBSERVED RESULT digiKam crashes. Last DebugView trace reads: 00000367 48.04353714 [18128] digikam.metaengine: Exiv2 ( 2 ) : iconv: Illegal byte sequence (errno = 42) inbytesleft = 4 EXPECTED RESULT digiKam does not crash. Maybe ExifTool can be used as a fallback? SOFTWARE/OS VERSIONS Windows: Windows 10 Pro 22H2 19045.3803 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: 5.245.0 Qt Version: 6.6.0 ADDITIONAL INFORMATION
digiKam 8.3.0 + Exiv2 0.27.6 + Linux Kubuntu 23.10 : not crash: https://i.imgur.com/Cfw1Zsk.png Please try with digiKam 8.3.0 pre-release installer for Windows available here : https://files.kde.org/digikam/ Gilles Caulier
Just tested with digiKam-8.3.0-20240124T094137-Win64, same crash.
The 8.3.0 preview build came with Exiv2.dll v0.28.1, according to Components Information. If I remove Exiv2.dll from the folder, digiKam switches to using ExifTool and does not crash. https://i.imgur.com/xX3rRbD.jpg
How digiKam can run with Exiv2.dll ??? Even if you use ExifTool backend, Exiv2 still used internally to parse metadata contents. ExifTool is only used to acces file contents (read/write). This one transfrom data read to Exiv2 container and vis-versa. Gilles Caulier
It looks like I had a separate install of Exiv2 v0.28.1 in %PATH%, and that's where it was getting the DLL from after I removed the one installed with 8.3.0. Sorry for the confusion.
and where come from this other Exiv2 dll ? which version exactly ?
The Exiv2 exception occurs in this call, after which no more code is executed, branched out by try/catch. https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/metadataengine/engine/metaengine_p.cpp?ref_type=heads#L591 Maik
(In reply to caulier.gilles from comment #6) > and where come from this other Exiv2 dll ? which version exactly ? It's the Windows build of 0.28.1 available here: https://exiv2.org/download.html https://github.com/Exiv2/exiv2/releases/download/v0.28.1/exiv2-0.28.1-2019msvc64.zip I tested a few more times with the other .dll removed from %path%, and sometimes I get an extra trace when it crashes: [23880] digikam.metaengine: Exiv2 ( 2 ) : iconv: Illegal byte sequence (errno = 42) inbytesleft = 4 [23880] [23880] digikam.metaengine: ExifToolProcess::readOutput(): ExifTool command completed It also looks like there's three processes left running after the crash: conhost.exe and two exiftool.exe instances. https://i.imgur.com/H4cO175.jpeg
The digiKam 8.3.0 use also Exiv2 0.21 compiled with MSVC. The problem with ExifTool is know. Windows do not kill children process when parent die. What's great operating system. A file already exist in bugzilla about this topic. The other process conhost.exe do not come from digiKam... Gilles Caulier
Hi Maik, Exiv2 0.28.2 is out : https://github.com/Exiv2/exiv2/blob/v0.28.2/doc/ChangeLog I'm not sure if we must include this version in the bundles. For Windows, VCPKG still branched to 0.28.1. Under the MXE build, we still to 0.27 as the Exiv2 MingW support is completely broken with the file path encoding under Windows. MacOS and AppImage can be ported to this version if necessary... Gilles
We also have the problem with the file path encoding with the VCPKG build. Which I don't understand since this build was supposed to use Windows' Utf8 API. But it's not a problem because in this case we automatically fall back to ExifTool - so it's just a performance problem. Maik
Do you means that i can switch also the Exiv2 version for MXE to 0.28.x now ? Gilles
Yes, in case of a file read error due to file path encoding (Exiv2 Error #10), we automatically read with ExifTool and decode the container with Exiv2 so that all metadata is present. Maik
The problem would only be when writing metadata if ExifTool is not activated, as we do not automatically switch to ExifTool when writing. Maik
well under Windows, we will needs to turn on this option by default... right ? Gilles
In principle, the problem with the file path is not that common, only with file paths whose characters are outside the current Windows code page. This should only occur very rarely for most Windows users. We could also automatically switch to ExifTool when writing metadata. We just have to look at the strategy when writing - read only files and sidecar settings. I also have the QIODevice Exiv2 file handler in the queue. This is almost completely fixed. There is only one crash with the Exif thumbnail reading function because the QIODevice file handler is currently not holding the read buffer, but that can be implemented. Maik
Ok, So it's not urgent to update Exiv2, especially in MXE, as it's a legacy version of Windows installer. Gilles
*** Bug 481735 has been marked as a duplicate of this bug. ***
Git commit cb335c2e95de4a5927c888894d5baf3612450802 by Maik Qualmann. Committed on 24/02/2024 at 21:59. Pushed by mqualmann into branch 'master'. add special case for unicode decoding in Exif.Photo.UserComment Related: bug 481735 FIXED-IN: 8.3.0 M +2 -2 NEWS M +8 -4 core/libs/metadataengine/engine/metaengine.cpp M +2 -0 core/libs/metadataengine/engine/metaengine_data_p.cpp M +5 -4 core/libs/metadataengine/engine/metaengine_data_p.h M +9 -4 core/libs/metadataengine/engine/metaengine_fileio.cpp M +47 -28 core/libs/metadataengine/engine/metaengine_p.cpp M +9 -7 core/libs/metadataengine/engine/metaengine_p.h https://invent.kde.org/graphics/digikam/-/commit/cb335c2e95de4a5927c888894d5baf3612450802