Created attachment 128070 [details] AppCrash_digikam.exe_a87d1e1185b15a95c10681922e9142fba9f2de9_c7f11afd_ed8f20f2-9109-4a94-8e25-1c259616768b SUMMARY DigiKam randomly shuts down in middle of operation, Windows event viewer reports crash. Noticed when browsing photos and assigning tags, thankfully have not noticed data loss. STEPS TO REPRODUCE 1. Happens randomly, have not noticed a specific scenario which consistently crashes. 2. So far have only noticed it when browsing photos and assigning, editing tags. 3. OBSERVED RESULT program randomly shuts down EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION Windows Error Report: Fault bucket 1571343157546872218, type 4 Event Name: APPCRASH Response: Not available Cab Id: 0 Problem signature: P1: digikam.exe P2: 0.0.0.0 P3: 5db9dcc2 P4: DImg_TIFF_Plugin.dll P5: 0.0.0.0 P6: 5db9dbe1 P7: c0000005 P8: 00000000000049b0 P9: P10: Attached files: \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERB433.tmp.mdmp \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERB8E7.tmp.WERInternalMetadata.xml \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERB907.tmp.xml \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERB905.tmp.csv \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERB926.tmp.txt These files may be available here: \\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_digikam.exe_a87d1e1185b15a95c10681922e9142fba9f2de9_c7f11afd_e5ba78da-4899-4a1a-9221-df312fe418bb Analysis symbol: Rechecking for solution: 0 Report Id: 9112c18d-7b9a-41d6-9c45-7d76c4954f77 Report Status: 268435456 Hashed bucket: df429d41379e121e45ce8846c5d26d9a Cab Guid: 0 Windows Application Error: Faulting application name: digikam.exe, version: 0.0.0.0, time stamp: 0x5db9dcc2 Faulting module name: DImg_TIFF_Plugin.dll, version: 0.0.0.0, time stamp: 0x5db9dbe1 Exception code: 0xc0000005 Fault offset: 0x00000000000049b0 Faulting process id: 0x2cb8 Faulting application start time: 0x01d61f872be1b561 Faulting application path: C:\Program Files\digiKam\digikam.exe Faulting module path: C:\Program Files\digiKam\plugins\digikam\dimg\DImg_TIFF_Plugin.dll Report Id: 24917a6c-ff25-4167-aed6-652e45852d4b Faulting package full name: Faulting package-relative application ID:
In DK 7.0.0, i recently updated the libtiff used internally. Can you reproduce the crash with the last RC published here : https://files.kde.org/digikam/ Gilles Caulier
(In reply to caulier.gilles from comment #1) > In DK 7.0.0, i recently updated the libtiff used internally. Can you > reproduce the crash with the last RC published here : > > https://files.kde.org/digikam/ > > Gilles Caulier I assume you are referring to this build? Or should I install the latest Win64 build? digiKam-7.0.0-rc-20200501T104952-Win32.exe Any issues moving from a Win64 build to a Win32 build? I am currently on: digiKam-6.4.0-Win64.exe Thx, Jose
FYI, I can be working for hours on the applicaiton and once the error occurs, all I have to do is select my root picture directory after restarting the app and it will crash within a minute. I know that I have some very large TIFF files, could that be the source of the issue? Jose
Use the 64 bits version, especially if you handle large tiff files. Remember that 32 bits version is limited to 4Gb or RAM. This is for the old computers. All desktop/laptop computers are based on 64 bits processor now. Gilles Caulier
I am downloading the RC and will install and test tomorrow. I was able to test and reproduce the issue - I have two very large TIFF scans, one is 1.6G and as soon as DigiKam saw the photo in a photo directory, it crashed. As soon as I moved it out of the photos directory, no more problems. BTW, if put it in an "ignored directory", it looks as if DigiKam scans all directories before it ignores it so it even crashed if it was in an ignored directory. I will report back tomorrow on what I find after I install the updated RC. Jose
I currently working to compile whole digiKam Windows bundles with a more recent GCC tto have a better C++ exception handling. See this commit : https://invent.kde.org/kde/digikam/-/commit/5828607054c0b4959e9bdef3466327901ff3b4f2 This king of situation where big tiff riquire too much of memory to allocate crash the session, even if the C++ exception is generated to prevent this crash. It's know that older GCC version do not work well in this kind of situation (currently DK is compiled with GCC 5.5 under Windows). I successfully compiled the 32 bits version with GCC 8.2. I will try now the GCC 9 (the more recent version). If all is fine, 32 and 64 bits DK using GCC 9 will be published in the day... Gilles Caulier
Git commit c1c0133b137f03a0bdb68b731156e3bbb69587c3 by Gilles Caulier. Committed on 03/05/2020 at 07:58. Pushed by cgilles into branch 'master'. Switch to GCC version 9 to compile all Windows bundles with MXE M +2 -2 project/bundles/mxe/01-build-mxe.sh https://invent.kde.org/kde/digikam/commit/c1c0133b137f03a0bdb68b731156e3bbb69587c3
Maik, Windows bundles are now fully compiled with GCC 9.3, not default GCC 5.5... Gilles
Great, a first test here with a broken PNG sample shows no crash. It is displayed up to the image error without crashing. Maik
Created attachment 128204 [details] Crash logs from 6 May 2 crash logs included, 1 from 1 May build, 2nd from 6 May build.
Sorry for the delay in testing RCs. I installed both the version from 1 May (digiKam-7.0.0-rc-20200501T123827-Win64.exe) and 6 May (digiKam-7.0.0-rc-20200506T124345-Win64.exe) and both experienced the same crash, logs are attached.
Forgot to ask, should I continue to run this RC or fall back to 6.4?
The Windows log files are unfortunately not helpful for us. They give no information as to what exactly is the cause. Can you isolate a TIFF file that causes a crash and make it available? DebugView (Microsoft) output might help more. However, you would have to set an environment variable with the RC. Set environment variables in Windows: Variable: QT_LOGGING_RULES Value: digikam.*=true Download DebugView from Microsoft and start it. Post the messages from start of digiKam to crash. Maik
And... yes, please continue to use daily build of RC version. It include all last changes to try to fix your crash... Best Gilles Caulier
Maik, I have a copy, let me know where I can download it to, it is 1.6G in size - hopefully it will let you duplicate the error. If not, I have no problem helping to get debug info, however I am not very experienced with generating it, let me know what you need and how to generate it and I will do my best to get it to you. Jose
Hi Josec, We must understand why the application down unexpectedly under Windows with this kind of situation. At least, application must report an error when allocating huge memory is not possible, not crashing. Also, we must check under Linux if the problem is also reproducible. Typically, no, because i'm sure that huge memory allocation is possible if ressource permit, else a fail back is provided properly. I do it in my office, in a real time acquisition application used in production (using 16b or ram in a circular buffer)... Gilles Caulier Gilles Caulier
I made a copy of the file and altered the face so it wasn't recognizable and placed it on dropbox where you can download a copy, the link is: https://www.dropbox.com/s/8t3vbxz3ltz6bwt/2018-11-23-0007%20copy.tif?dl=0 I did put it in a folder under the dk root and validated this file caused my version of dk to crash in the same manner. If there is any more troubleshooting you'd like me to perform, let me know. Jose
Created attachment 128245 [details] DebugView Log Output I ran debugview with the environment variables set as you said and attached the log file output. You can see the program started up at 5:26:46.628 and crashed at approximately 5:27. I checked the windows logs and the crash was reported at 5:27:12. I then waited about 10 minutes before I closed down debugview.
Git commit 8b18fb20f5eda64f73f5e3867af95f448e8dbf40 by Maik Qualmann. Committed on 10/05/2020 at 19:49. Pushed by mqualmann into branch 'master'. fix memory request for very large images Related: bug 416266 M +3 -1 core/libs/dimg/dimg_data.cpp https://invent.kde.org/kde/digikam/commit/8b18fb20f5eda64f73f5e3867af95f448e8dbf40
I just installed the latest RC, digiKam-7.0.0-rc-20200512T190316-Win64.exe and experienced the same crash. Let me know if there is any other data collection you would like me to perform. As always, grateful for the support... Jose
There is no longer a general problem with large files. I can load the image on Linux. However, automatic exif rotation or conversion to 8 bit must be deactivated, otherwise it will be tight with 8GB memory. We have to debug it on Windows... Maik
Not sure if replying to this old ticket is the appropriate way to report, but this looks like basically the same problem I experienced before. DigiKam is crashing on startup after getting through 15% of "Finding new items" and I am getting what looks like the same error message in Windows logs: Faulting application name: digikam.exe, version: 0.0.0.0, time stamp: 0x00000000 Faulting module name: DImg_TIFF_Plugin.dll, version: 0.0.0.0, time stamp: 0x00000000 Exception code: 0xc0000005 Fault offset: 0x00000000000043d5 Faulting process id: 0x3a1c Faulting application start time: 0x01d65d2975f129e3 Faulting application path: C:\Program Files\digiKam\digikam.exe Faulting module path: C:\Program Files\digiKam\plugins\digikam\dimg\DImg_TIFF_Plugin.dll Report Id: 7749097c-d187-4ef4-a881-b3b3a73023af Faulting package full name: Faulting package-relative application ID: I tried moving any large TIF files out of the pictures directory which did not help, so I ran MS DebugView and attached the output. I did notice that it lookd as though DK was having problems with my *.afphoto" files which is my Affinity editor output. I am running the latest RS from June 2020.
Created attachment 130225 [details] MS DebugView Output 18 Jul
Sorry, running the latest RC...
Can you the file: "D:/Users/Jose/Pictures/Scans Folder/Family Scans/2018-11-23-0007 v2.tiff" to make available for testing, if not public, also as private mail? And please test with the current build of digiKam-7.0.0: https://files.kde.org/digikam/ Maik
Created attachment 130309 [details] Zipped/Compressed TIFF File Maik, The file is attached, I don't remember how I generated it or the program I used to generate it but the info on the file doesn't make much sense. I installed the latest update which did not help however as soon as I pulled that file out of the directory, DK ran with no issue. Jose
The image is compressed with Adobe Deflate. First I suspect that digiKam does not support this compression method. If it is loaded here with Gwenview (QImage loader) or Gimp, it looks very blocky. Maik
Maik, Yes, libtiff support defate compression. In fact its GNU zip like method. Of course libtiff must be compiled with this support. If you look to image editor Tiff file save options, a compression checkbox is available : it's deflate stuff... https://imgur.com/iDmuhpw Gilles
digiKam 7.0.0 stable release is now published: https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/ We need a fresh feedback on this file using this version. Thanks in advance Gilles Caulier
Created attachment 130529 [details] MS Debugview Output 31 July I upgraded to the new R7 distribution and ran it without the file in question in the album and it worked no problem. I then put the file back in the album and it crashed. Same file I used before, the compressed TIFF file.
digiKam 7.2.0 official release is published with more than 360 files closed from bugzilla: https://www.digikam.org/news/2021-03-22-7.2.0_release_announcement/ Can you reproduce the dysfunction with this version ? Thanks in advance for your feedback Gilles Caulier
Created attachment 137739 [details] DK Large TIFF Crash
Sorry about taking so long to get to this, I was able to test and I had the same result, the output of MS DebugView is attached. I moved the folder with the large TIFFs back into my main DK album, since the last activity I was doing with DK was facial recognition, it started up where I left off. After starting, I let DK sit for about 20 minutes and there were no issues. I then navigated to the album tab (event 1545) and about a minute later, it crashed.
Can you make the file "D:/Users/Jose/Pictures/Large TIF/2018-11-23-0007 v2.tiff" available, if not public, then on my private mail? Maik
I just see we already have them ... Maik
Josec, Stable digiKam 7.4.0 is published. Please check if problem is reproducible. https://www.digikam.org/download/ Thanks in advance
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 448645, bug 425886, bug 431118 M +9 -9 core/dplugins/dimg/tiff/dimgtiffloader_load.cpp https://invent.kde.org/graphics/digikam/commit/5c8108678c1c62be48afab2c4bdb1634f38a1b14