SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** Clicking Browse > Labels causes a program crash 100% of the time. STEPS TO REPRODUCE 1. Click Browse > Labels 2. 3. OBSERVED RESULT When clicking Browse > Labels Digikam briefly displays the labels menu in left panel, system resource use spikes, Digikam freezes moments before crashing. This same sequence happens every time, regardless of how long the program has been running, what other programs are running. Same behavior was observed in 7.4.0. Just upgraded to 7.5.0 with no difference. I don't use Labels, I don't think I've ever assigned any, so this bug is not important to my personal workflow but thought you would like to know about it anyway. EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: 11 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Please download DebugView from Microsoft and set the Qt Debug environment variable as described here for Windows and send the log: https://www.digikam.org/contribute/ Maik
Created attachment 145657 [details] DebugView log
(In reply to Maik Qualmann from comment #1) > Please download DebugView from Microsoft and set the Qt Debug environment > variable as described here for Windows and send the log: > > https://www.digikam.org/contribute/ > > Maik Thanks, I just did that and attached the DebugView log to the bug report.
Reading your trace i have some Q : - Did you have a log file here : C:\\Users\\LocalUser\\AppData\\Local\\digikam_crash.log - You have plenty of JPEG file which do not are JPEG images in fact : E:/OneDrive/Whiskeytown/photos/August_09.jpg" : Not a JPEG file: starts with 0x4a 0x65 Drive E: is corrupted ? Gilles Caulier
The crash occurs with this TIFF file: "E:/OneDrive/Rodeo Beach/Rodeo archives/MAHE_historic/pt_boneta2.tif" We already know of crashes with TIFF files under Windows, but the cause is not yet clear. Maik
See bug https://bugs.kde.org/show_bug.cgi?id=425886
(In reply to caulier.gilles from comment #4) > Reading your trace i have some Q : > > - Did you have a log file here : > > C:\\Users\\LocalUser\\AppData\\Local\\digikam_crash.log > > - You have plenty of JPEG file which do not are JPEG images in fact : > > E:/OneDrive/Whiskeytown/photos/August_09.jpg" : Not a JPEG file: starts with > 0x4a 0x65 > > Drive E: is corrupted ? > > Gilles Caulier Hi. No, there was no digikam_crash.log file created, I ran the sequence multiple times but that file was never created. Digikam does freeze and close each time however. Drive E is not corrupted, I've scanned it for errors and it's functioning normally. I'll look at those individual .jpg files to see if they display as images
(In reply to Maik Qualmann from comment #5) > The crash occurs with this TIFF file: > > "E:/OneDrive/Rodeo Beach/Rodeo archives/MAHE_historic/pt_boneta2.tif" > > We already know of crashes with TIFF files under Windows, but the cause is > not yet clear. > > Maik Thanks. I can confirm that E:/OneDrive/Whiskeytown/photos/August_09.jpg is a corrupt file and does not display in any other programs. However, trying to open August_09.jpg does not crash DigiKam or cause any other problems. Previewer simply says "Failed to load image". Also can confirm that opening the directory in Digikam with E:/OneDrive/Rodeo Beach/Rodeo archives/MAHE_historic/pt_boneta2.tif in it causes the crash. So it's not limited to the Browse>Labels action. As soon as I open that folder in Digikam to display the thumbnails, Digikam crashes. I can confirm that E:/OneDrive/Rodeo Beach/Rodeo archives/MAHE_historic/pt_boneta2.tif is a valid TIF, and that it opens with other photo viewers just fine (GIMP, Windows Photo Viewer). pt_boneat2.tif is 70,425 KB.
Can you please provide this TIF file for us to investigate, if not publicly to my private mail. Maik
(In reply to Maik Qualmann from comment #9) > Can you please provide this TIF file for us to investigate, if not publicly > to my private mail. > > Maik No problem, download link below. It's a public domain historic document: https://1drv.ms/u/s!AiBDufMJfMahktNu6wRLQTf1K9EtiQ
Git commit 5c8108678c1c62be48afab2c4bdb1634f38a1b14 by Maik Qualmann. Committed on 20/01/2022 at 19:52. Pushed by mqualmann into branch 'master'. the type long probably only has 32 bits under Windows But this is not enough as an offset counter. Related: bug 425886, bug 420868, bug 431118 M +9 -9 core/dplugins/dimg/tiff/dimgtiffloader_load.cpp https://invent.kde.org/graphics/digikam/commit/5c8108678c1c62be48afab2c4bdb1634f38a1b14
(In reply to Maik Qualmann from comment #11) > Git commit 5c8108678c1c62be48afab2c4bdb1634f38a1b14 by Maik Qualmann. > Committed on 20/01/2022 at 19:52. > Pushed by mqualmann into branch 'master'. > > the type long probably only has 32 bits under Windows > But this is not enough as an offset counter. > Related: bug 425886, bug 420868, bug 431118 > > M +9 -9 core/dplugins/dimg/tiff/dimgtiffloader_load.cpp > > https://invent.kde.org/graphics/digikam/commit/ > 5c8108678c1c62be48afab2c4bdb1634f38a1b14 Here's the thing: I have lots of large TIFFs that don't crash Digikam. Download link below for BaldMtn_Ackerson1935.tif (130MB) that previews and opens in DK image editor just fine. There are several TIFFs of this size in the same directory and they all work. I've logged a DebugView session of me opening up BaldMtn_Ackerson1935.tif in DK successfully and then manually closing DK (no errors, no crash). https://1drv.ms/u/s!AiBDufMJfMahktBOnkFD86bqYaQbog
Created attachment 145679 [details] DebugView_successful_large_tif
I'm pretty sure that the problem with TIF files on Windows is fixed now. We'll see when a new Windows bundle becomes available. It depends on how the TIF is encoded whether the problem occurs. It depends on the size, your first TIF has about 21000x26000 pixels, your second is 16 bit, but only about 7000x3000 pixels. Maik
(In reply to Maik Qualmann from comment #14) > I'm pretty sure that the problem with TIF files on Windows is fixed now. > We'll see when a new Windows bundle becomes available. It depends on how the > TIF is encoded whether the problem occurs. > > It depends on the size, your first TIF has about 21000x26000 pixels, your > second is 16 bit, but only about 7000x3000 pixels. > > Maik Wonderful, thanks so much! I <3 Digikam and will continue to support with donos and bug reports! Much appreciated.
The data type long is 64 bit under Unix on a 64 bit platform (32 bit on a 32 bit platform). Therefore we have no problems with very large TIF files. According to my research, long under Windows should only have 32 bits even on a 64 bit platform. Maik
(In reply to Maik Qualmann from comment #16) > The data type long is 64 bit under Unix on a 64 bit platform (32 bit on a 32 > bit platform). Therefore we have no problems with very large TIF files. > According to my research, long under Windows should only have 32 bits even > on a 64 bit platform. > > Maik Did you solve by changing data type to 'LONGLONG' for Windows? https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types
(In reply to wolfelkbeaver from comment #17) > (In reply to Maik Qualmann from comment #16) > > The data type long is 64 bit under Unix on a 64 bit platform (32 bit on a 32 > > bit platform). Therefore we have no problems with very large TIF files. > > According to my research, long under Windows should only have 32 bits even > > on a 64 bit platform. > > > > Maik > > Did you solve by changing data type to 'LONGLONG' for Windows? > > https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types Now I see that you solved it by changing 'long' to 'qint64'. Thanks and I look forward to the next release with the change. I'll report back on how it works.
Right, longlong would also be a solution, but we like to use Qt types because they guarantee the right type on all platforms. Yes, we'll see if it solves that problem with the next Windows bundle. Maik
A new Windows test version is available. Please test if the TIF image still crashes digiKam. https://files.kde.org/digikam/ Maik
(In reply to Maik Qualmann from comment #20) > A new Windows test version is available. Please test if the TIF image still > crashes digiKam. > > https://files.kde.org/digikam/ > > Maik Hi Maik, No crash now. I installed 7.6.0-Win64-debug and was able to preview and open the large TIF that crashed 7.5.0. Thanks!
Thanks for the feedback and testing, I'm closing the bug now. Maik