Bug 425096 - Crash Unsupported JPEG process: SOF type 0xc8
Summary: Crash Unsupported JPEG process: SOF type 0xc8
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Faces-Detection (show other bugs)
Version: 7.0.0
Platform: Microsoft Windows Microsoft Windows
: NOR crash
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-07 06:25 UTC by Proffecanded
Modified: 2020-10-04 01:56 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.2.0


Attachments
Dr. Mingw crash (273.31 KB, text/plain)
2020-08-07 06:25 UTC, Proffecanded
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Proffecanded 2020-08-07 06:25:19 UTC
Created attachment 130697 [details]
Dr. Mingw crash

SUMMARY
Face detection crashes with error Unsupported JPEG process: SOF type 0xc8.
Running digikam on windows crashes always at the same scanning percentage. The same app version under Ubuntu crashes randomly on the same image set.
I'm unable to find the image causing crash.


STEPS TO REPRODUCE
1. Open app
2. Wait for new files detection
3. Click "scan collections for faces"

OBSERVED RESULT
digikam crash

EXPECTED RESULT
Faces scan goes on and finishes


SOFTWARE/OS VERSIONS
Windows: Windows 10 2004
Linux/KDE Plasma: Linux Focal Fossa
(available in About System)
KDE Frameworks 5.68.0
Qt 5.12.8 (built against 5.12.8)

ADDITIONAL INFORMATION

DEBUGVIEW
[14296] QCommandLineParser: already having an option named "?"
[14296] QCommandLineParser: already having an option named "help-all"
[14296] QCommandLineParser: already having an option named "v"
[14296] KMemoryInfo: Platform identified :  "WINDOWS"
[14296] KMemoryInfo: TotalRam:  34282037248
[14296] MaterialIcons cannot be loaded !
[14296] kf5.kxmlgui: Unhandled container to remove :  Digikam::DigikamApp
[14296] QLayout: Attempting to add QLayout "" to QWidget "", which already has a layout



DR.MINGW
See attached file
Comment 1 Maik Qualmann 2020-08-07 06:40:30 UTC
The problem is clear the exception handling in MinGW at 64 bit has an error and jumps to the wrong function "msvcrt.dll! __ longjmp_internal". The digiKam Windows 32 bit version should not crash here. We haven't found a workaround for this at the moment to bypass the error in MinGW.

Maik
Comment 2 Proffecanded 2020-08-07 06:42:30 UTC
How I can find the image causing the crash?
Comment 3 Maik Qualmann 2020-08-07 06:47:16 UTC
Set environment variables in Windows:

Variable: QT_LOGGING_RULES
Value: digikam.*=true

DebugView now shows more messages and should also show the image with path of what is currently being loaded.

Are you really on the current digiKam-7.0.0 version, your Qt version is so old. That doesn't match digiKam-7.0.0.

Maik
Comment 4 Maik Qualmann 2020-08-08 19:08:03 UTC
Git commit fc22d48c0b59828bbd1229a023c3edc5b50980b8 by Maik Qualmann.
Committed on 08/08/2020 at 19:06.
Pushed by mqualmann into branch 'master'.

try with built in setjmp/longjmp function for MinGW
Related: bug 425063

M  +8    -0    core/dplugins/dimg/jpeg/dimgjpegloader.cpp
M  +8    -0    core/dplugins/dimg/jpeg/dimgjpegloader_load.cpp
M  +8    -0    core/dplugins/dimg/jpeg/dimgjpegloader_save.cpp
M  +16   -0    core/libs/jpegutils/jpegutils.cpp

https://invent.kde.org/graphics/digikam/commit/fc22d48c0b59828bbd1229a023c3edc5b50980b8
Comment 5 Proffecanded 2020-08-16 17:15:54 UTC
I set the environment variable and found the image causing crash. It's a 70MB panoramic photo. I tried to scan again the whole folder but digikam doesn't crash anymore.
I've compiled latest version including your commits. I'll launch faces scan as soon as possible.
Comment 6 Proffecanded 2020-08-17 05:51:15 UTC
I can't reproduce bug with commit 536c505d96df7434c30a2a94e03e57759f686186.
Comment 7 Maik Qualmann 2020-08-17 07:20:01 UTC
You made a 64 bit Windows build and tested it? A Linux compilation would not help, the error only affects Windows.

Maik
Comment 8 Proffecanded 2020-08-17 08:50:23 UTC
Yes I did. I compiled it with mxe.
Could it be related to a memory leak or the bug was fixed in version 7.1.0.
Comment 9 caulier.gilles 2020-10-04 01:56:56 UTC
Fixed with #425063