Created attachment 118654 [details] Windows crash message SUMMARY In "Slideshow" or "Presentation", digiKam crashes after a couple of images. "A couple" can be anything between 1 and 50 or so, but so far it has always crashed. STEPS TO REPRODUCE 1. Select an Album with a sufficiently large number of images. 2. Start "Slideshow - All" OR 1. Select a sufficiently large number of images. 2. Do "Presentation" (everything unchecked; 4 seconds; Effect None). OBSERVED RESULT digiKam crashes after an arbitrary number of images shown. It has happened right after the first one, it has happened after 40 or more, but it always crashes sooner or later. EXPECTED RESULT No crash. SOFTWARE/OS VERSIONS Windows: Win 7 32bit ADDITIONAL INFORMATION Memory should not be a problem because Task Manager does not show an increase in memory consumption; it is stable around 2 GB.
Please try to reproduce the problem with current 6.1.0 installer for Windows (pre release), where code have been well patched by Maik... https://files.kde.org/digikam/ Gilles Caulier
Created attachment 118684 [details] 6.1.0 start error message Ok, tried that. When starting, the attached error message shows up, but digiKam starts nonetheless. - Slideshow: Crashes as before (once after 2, once after 11 pictures). - Presentation, standard transition "None": Screen remains black. Depending on number of images selected, either comes to the regular end of the presentation, or crashes before that. - Presentation, OpenGL transition "Fade": Ran through a presentation of 340 pictures without crashing! And it seems to be centered! However... No images are displayed; just a white screen that fades in and out. Kind regards, Harald
This error message is due to my last DrMinGW update. I will fix it. Gilles Caulier
Git commit d37592eb30115e8bd196e6ef4a000ef9111d925b by Gilles Caulier. Committed on 10/03/2019 at 18:20. Pushed by cgilles into branch 'master'. compile DrMinGw with MXE instead to use pre-compiled DLL M +14 -46 project/bundles/3rdparty/ext_drmingw/CMakeLists.txt A +15 -0 project/bundles/3rdparty/ext_drmingw/drmingw-coreonly.patch https://commits.kde.org/digikam/d37592eb30115e8bd196e6ef4a000ef9111d925b
Harald, The 6.1.0 pre-release installer have been updated this morning. Please test and report : https://files.kde.org/digikam/ Gilles Caulier
Gilles, The following is for digiKam-6.1.0-git-20190315T074305-Win32. - No error message at startup anymore. - Slideshow: Crashes. However, it now seems to consistently show the first picture and crash when transitioning to the second. - Presentation, standard transition "None": Screen remains black; always crashes sooner or later. Can't say if behavior has changed or not. - Presentation, OpenGL transition "Fade": Same behavior as before. Doesn't crash but only shows white screen instead of pictures fading in and out. Kind regards, Harald
If it crash, you must see a crash backtrace file generated by DrMinGW in your home directory : C:\Users\_user_name_\AppData\Local\digikam_crash.log Gilles Caulier
Created attachment 118821 [details] Log for "Slideshow"
It's clear, there is a memory allocation error : digikam.dimg: Failed to allocate chunk of memory of size 64131072 std::bad_alloc Do you found the crash backtrace file ? Gilles Caulier
Created attachment 118822 [details] Log for "Presentation" with OpenGL transition Behavior was different from the one described before. It did not show just white screens, but alternating the first image and a white screen.
Created attachment 118823 [details] Log for "Presentation" with transition "None"
Created attachment 118824 [details] Screenshot of Task Manager while running digiKam Ok, the predictability (Slideshow always crashes after first image) I have to take back; it just ran through a slideshow of 5 images without crashing. Without knowing the details, the logs attached before seem to indicate a memory problem on my machine. However, to me, this doesn't seem to be the case. In the attached screenshot, the interesting part (i.e. where digiKam is running) is the right half. Idle; digiKam starts; slideshow with 5 images without crash; new slideshow with crash. At any rate, the memory available seems to be more than sufficient. At least it was to what I was running before starting digiKam, as can be seen in the left half. Best regards, Harald
Created attachment 118847 [details] Crash log Gilles, When I let it crash today, it doesn't seem to write a crash log. However, there is a log from yesterday, but I don't remember in which situation(s) it was created. Hope it helps nonetheless. Kind regards, Harald
The file backtrace group more than one crashes. All are concatenated. Do you have video files to play while Slideshow ? I see plenty of crashes in QtAV module which is used to render video on the screen. Gilles Caulier
Gilles, No, no video. Only jpeg files. I saw that there were several crash reports in the log. However, I must have crashed it at least 50 times; I don't find *that* many entries. Also, when I delete (or rename) the log and then crash digiKam, it doesn't start a new log file. So it seems to me that the majority of crashes are not logged. Of course, this may be desired behavior. Best regards, Harald
Git commit 3353509269a647f9e4f68ae36241ff80461b45b0 by Maik Qualmann. Committed on 17/03/2019 at 18:22. Pushed by mqualmann into branch 'master'. add checks if QImage is NULL M +10 -0 core/dplugins/generic/view/glviewer/glviewertexture.cpp M +13 -4 core/dplugins/generic/view/presentation/common/presentationloader.cpp https://commits.kde.org/digikam/3353509269a647f9e4f68ae36241ff80461b45b0
Git commit 6e764908da4651eeb60d45b32cfd138b122703ca by Maik Qualmann. Committed on 17/03/2019 at 18:59. Pushed by mqualmann into branch 'master'. better check for OpenGL availability M +3 -3 core/dplugins/generic/view/glviewer/glviewerwidget.cpp M +20 -0 core/dplugins/generic/view/presentation/opengl/presentationgl.cpp M +2 -0 core/dplugins/generic/view/presentation/opengl/presentationgl.h M +20 -0 core/dplugins/generic/view/presentation/opengl/presentationkb.cpp M +2 -0 core/dplugins/generic/view/presentation/opengl/presentationkb.h M +2 -2 core/dplugins/generic/view/presentation/presentationmngr.cpp https://commits.kde.org/digikam/6e764908da4651eeb60d45b32cfd138b122703ca
The log of Comment 11 is not from the Presentation but from the Slideshow. You have no more memory to load a 16 MPixel image. The slideshow tries as an alternative now the video loader and crashes. Ok, I can change that, but your memory is not enough, digiKam can not change that. Maik
Git commit ede14ddcf215d0a55cf3aa84c94296e0fb9e8240 by Maik Qualmann. Committed on 17/03/2019 at 21:30. Pushed by mqualmann into branch 'master'. try not to load with QImage anymore, preview thread already does it M +0 -6 core/dplugins/generic/view/presentation/opengl/kbimageloader.cpp https://commits.kde.org/digikam/ede14ddcf215d0a55cf3aa84c94296e0fb9e8240
Git commit 187f53b0ef3cee38a240ca01563884e035137e1d by Maik Qualmann. Committed on 17/03/2019 at 21:34. Pushed by mqualmann into branch 'master'. do not try the video loader if the image failed to load M +2 -11 core/utilities/slideshow/slideshow.cpp https://commits.kde.org/digikam/187f53b0ef3cee38a240ca01563884e035137e1d
(In reply to Maik Qualmann from comment #18) > The log of Comment 11 is not from the Presentation but from the Slideshow. Maik, Well, it was the log that I found at the location described by Gilles. I couldn't get digiKam to write a new log. > You have no more memory to load a 16 MPixel image. . That was my conclusion, too, but something is not right here. If you look at the Task Manager screenshot in Comment 12, it shows that there was about 1.5 GB of memory available when it crashed (3 boxes from the right). Best regards, Harald
Created attachment 119077 [details] digiKam and 20 instances of IrfanView Maik, So I'm not going to give up easily... Just to show that the problem *cannot* be lacking memory in my machine, I did the following: - started digiKam - started Slideshow => crashed (as expected) - restarted digiKam - started 20 instances of IrfanView, with a 16-MP image each Details in the attached commented screenshot. So, the reason for the crash cannot be that there is not enough memory for a 16-MP image. Something else must be amiss. Best regards, Harald
Created attachment 119078 [details] Crash message Something else I noticed: Most of the time (I'd say at least 19 out of 20) when digiKam crashes, it displays the attached message and *does not* write into digikam_crash.log. This was the case in the first crash in my experiment described before.
Created attachment 119079 [details] Crash log In the second crash, however, the message was not displayed, and a crash log entry was created. See attached. Best regards, Harald
Are you really using the last available Windows version of digiKam? I do not think so, because the video player should not appear in the crash log, because in a faulty image load only with GIF images of the video player is tried. Please upload a log with DebugView from start to crash. Maik
Created attachment 119119 [details] Slideshow log Mike, from March 15 onwards, I had used version digiKam-6.1.0-git-20190315T074305-Win32.exe. Before that, I had used the release version digiKam-6.0.0-Win32.exe. I just installed the latest build digiKam-6.1.0-git-20190328T175041-Win32.exe, so everything I write here refers to that version. First, the problem with the disappearing "Photograph Properties" seems fixed. For "Slideshow" and "Presentation", I now get weird results. Slideshow: Each picture in the slideshow is either shown for about 5 seconds, or it is skipped. I.e. either the screen remains black or the previous image continues to be displayed while the counter in the bottom left counts up one image per second. Hard to describe; I hope you get the idea. Example: - Picture 1 is shown; counter counts up from 1 to 5. - Picture 2 is skipped (i.e. picture 1 remains visible); counter shows "2/10" for one second. - Picture 3 is skipped, counter shows "3/10" for one second. - Picture 4 is displayed for 5 seconds. - Pictures 5 - 9 are skipped ("5/10" to "9/10" for 1 second each); picture 4 remains visible. - Picture 10 is displayed for 5 seconds. The first picture may or may not be black (but is always displayed for 5 seconds). For pictures that *are* displayed, the monitor color profile is not applied. Something really seems to be fundamentally wrong here. No crashes observed. Enclosed is a log for this situation. Best regards, Harald
Given that the log again indicates memory allocation problems but it is clear to me that my machine is not the problem (more than 1 GB free at time of running this): Might it be possible that there is some restriction in the amount of memory allocatable to this process? (Sorry, I have done quite a bit programming myself, but never Wintel). Still, this wouldn't explain why the monitor profile is not applied, would it. Oh, by the way, and before you ask: Other image processing software (Lightroom, RawTherapee, Gimp, IrfanView, Picasa) runs without any problems on my machine.
Created attachment 119121 [details] digiKAm crash log from Presentation without OpenGL transition Regarding Presentation, basically the same behavior as before. No OpenGL transition: Crashes immediately, sometimes with the Visual C++ error message displayed, sometimes not. Log attached. OpenGL transition: Runs without crashing, but only shows a white screen fading in and out, no actual images. Once, it has happened that the first image was displayed, albeit very unsharp (enlarged from a lower resolution preview, maybe?) Then a white screen, then the first (!) image again, then a white screen, and so on.
I take this from the LOG: digikam.dimg: Failed to allocate chunk of memory of size 64131072 std::bad_alloc digikam.dimg.jpeg: Cannot allocate memory! Reserving around 61 MB of memory for the image buffer fails. The digiKam JPEG Loader gives up. digikam.dimg.qimage: Can not load " "E:/Fotos/Testfotos Schottland/Linear/DSC06844.jpg" " using DImg::QImageLoader! digikam.dimg.qimage: Error message from loader: "Unable to read image data" Attempting to load the image with the QImage Loader provided in Qt also fails. I have no idea why memory allocation fails on your computer. Suspect that something prevents that only a limited amount of memory gets this process. Therefore, some images are displayed which are probably smaller in size and require less memory Maik
Maik, I understand that you cannot fix a problem that doesn't show up in your setup. So I guess I'll have to leave it at that. Should you have any further idea, or if you would like me to try or verify anything, please let me know. Best regards, Harald
Yes, at the moment I have no idea why the memory allocation fails. We use a C++ function Type* reserved = new Type[size] (Type can be unsigned char*). After the digiKam-6.1.0 release I will test it with the C function malloc(). For me, the only explanation is that your storage is fragmented and that there are not 60MB available. But as you already write, other programs would then have also problems. But this problem has not been reported a second time. Maik
Git commit dac492a5b7423ffc91eaa7cade358bf9aa685a54 by Maik Qualmann. Committed on 16/06/2019 at 08:24. Pushed by mqualmann into branch 'master'. check after allocating memory only for null pointer on Windows Related: bug 408471 M +10 -0 core/libs/dimg/loaders/dimgloader.h https://invent.kde.org/kde/digikam/commit/dac492a5b7423ffc91eaa7cade358bf9aa685a54
Check out this comment for a link to a recent GIT version of digiKam-6.2.0 on my GDrive: https://bugs.kde.org/show_bug.cgi?id=408471#c7 Maik
Hi there, I have a new machine now, 64bit Win10 Pro, and have installed digiKam 6.3.0. I have not observed any crashes or blank pages in Slide Show or Presentation anymore :-) Unfortunately, I won't be able to verify whether the problem is gone on my old machine (32bit Win7), too. However, a new observation: When using Presentation/OpenGL transitions, the image is not sharp. It looks as if a too-low-resolution image has been enlarged to fit the screen. Transition itself works. Presentation/standard transition works, Slideshow works. My graphics is Intel UHD P630. Kind regards, Harald
About presentation and low resolution image on monitor, look in digiKam Views/Preview if full image is used to render preview on screen. Best Gilles Caulier
The original problem from this file is solved. i close now. Gilles Caulier