*** On opening digiKam, I found that the menu bar was hidden. thinking I may have hit a ctrl-m, and given that I had the 3 line icon upper right, this all was consistent. Problem is, the Settings> config pop-out showed the 'Show Menubar' item as selected. I retried this (opened the menu via the 3 bars, I did not restart the app*), with no change. I unselected the menubar item, and then reselected it, and the menubar appeared. SUMMARY As above STEPS TO REPRODUCE Not sure if this is reproducable yet. It is reported because I havent seen it with this build (latest test build as of 6.3.25) except for this once. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: 10 macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION Per the *, the digikam process is not closing with the app- where this was a bug that had been fixed some months back but reappeared with the newer builds (the larger download package). So, its not clear to me if this is tied to multiple instances of that process (i.e. shared access to a settings table). So, not sure if there is a more complex setup for this to happen, or if this was just some random memory corruption thing etc. I reported it in the case others see it and can validate this is happening, where that might merit some eval into the setup (i.e. multiple instances of the program running, or one left running for some time (as was the case in this report), etc.
As you said, a concurrent instance of pending digiKam can be the origin of the problem. Typically, the RC settings file of digiKam used to store the application settings can be corrupted and give this kind of side effect. We haven't yet seen this kind of dysfunction before under Windows.
I have not seen it repeat, but I will keep an eye on it. As I said- I dont think this is something that is easy to reproduce. Could speculate all day- but I put this out here just in case others have seen it. If it exists, Ill keep a closer eye on context. I realize the process not ending was a prior bug, and I dont want to convolute this report, but is the issue with the digikam process remaining active active again? If not, I can reopen it or post it again- though it is trivial to reproduce at present (i.e. close the app). Aside from the potential for contested db access etc, it prevents a simple update- since the updated stub thinks the app is still running (well, it is still running, just not with a GUI)
About the pending process running in memory even if application have been closed, we have already seen this kind of feedback. It's due to the face scan detection or recognition running in background. It's your case?
No, in my setup, if I simply open the app, wait for it to initialize and show thumbnails, and then close it via the X on the menu bar, I see the digikam.exe process continue to run in task manager. While it shows 0% CPU usage, it shows 607MB RAM allocation that is not returned to the OS without a physical end task (or restart of system). I do not have any auto-anything enabled. Or at least, as best I can tell, I have this all disabled. Under Settings/Misc/Behavior, all items above the 'warning- these settings make startup slower' are unchecked. If there are other background processes I need to disable, please advise. Best Rob
I suspect something wrong with the face pipeline here... I move this file at the right place.
Run digiKam with DebugView to see what's happen at end of digiKam session. Follow instructions here : https://www.digikam.org/contribute/#windows-host
Hi Gilles, (In reply to caulier.gilles from comment #5) > I suspect something wrong with the face pipeline here... I move this file at > the right place. I do not think this is being caused by the any of the face pipelines because of what Roland said: > No, in my setup, if I simply open the app, wait for it to initialize and show thumbnails, and then close it via the X on the menu bar, I see the > digikam.exe process continue to run in task manager. While it shows 0% CPU usage, it shows 607MB RAM allocation that is not returned to the OS > without a physical end task (or restart of system). > I do not have any auto-anything enabled. Or at least, as best I can tell, I have this all disabled. Under Settings/Misc/Behavior, all items above the > 'warning- these settings make startup slower' are unchecked. If there are other background processes I need to disable, please advise. The only face pipeline that would be started is the Face Edit pipeline, that one is much simpler than the other pipelines. If CPU is 0% then none of the other pipelines are running. The other pipelines run usually consume 100% CPU (with Low thread priority) until they finish, and then the pipeline exits completely. @Roland, the debug that @Gilles suggested will be very useful. Cheers, Mike
You are right Michael. It's not probably the Face Engine working in the background. But 607 Mb lost ? I never seen that. Under Linux, valgrind never report something like this... Possible origin : the thumbnails engine and database storage. Roland, Which kind of database did you use ? Where are stored your collections ? Which kind of image/video files did you register in the database? Best Gilles Caulier
Hello. Sorry, I havent had time to debug. Perhaps tomorrow. As regards the database, Im running SQLite locally. I have several instances of digiKam configured (only 1 runs at a time (I make an effort to manually kill processes that dont terminate with the GUI, as this has been a problem since the new installer (the much larger download) was seen), per your notes on how to configure separate configuration profiles. One instance has a large number of files (approx 200,000) stored locally on an SSD. This is largely smaller jpg/png content (typically <200kb per). There are some number of relatively large photos- AI upsampled files in the 50MB range- probably 100 or fewer. There are some number of video files, but only for the purposes of renaming/organizing when the files are moved out to a separate storage system. In another instance, there are a moderate number of files (20,000) for a total about about 9GB- almost all <200KB jpg/png types. That instance has the content on a SAN (fast Ethernet- nearly as fast as local access), with the database local on an SSD. Another replicates that config, with far fewer images (more like 2,000)- though it has on average much larger files (typically RAW images in the 1-5MB range). The larger of the 3 collections doesnt run face recognition, but does have fingerprints. The medium sized instance has both facial and image fingerprint data. The smallest has only image fingerprints. In all 3 cases- if digiKam is started and then closed, I will see it hold between 602MB and 632MB until its process is killed. So, I dont know what is being cached, but given the huge disparity in file counts and image vs facial fingerprints, I would expect to see a much larger variance if images or thumbnails are being cached etc. Seems more plausible this is something like a thumbnail cache, where those are fixed pixel size. So, if the system holds say the last n thumbnails accessed in cache, that might explain why this value is relatively constant. The properly running application in idle mode (just some thumbnails showing- no secondary windows or tools active) holes about 1.3GB RAM in all 3 instances- so that doesnt seem to be sensitive to the number of files in the collection. Roland
Git commit 3c11e5e55ae021ab180bda270c3b45dd209d816f by Maik Qualmann. Committed on 05/06/2025 at 19:16. Pushed by mqualmann into branch 'master'. fix state from the menu bar view action after the start M +2 -0 core/app/main/digikamapp.cpp M +0 -1 core/app/main/digikamapp_setup.cpp M +2 -4 core/utilities/imageeditor/main/imagewindow.cpp M +2 -2 core/utilities/import/main/importui.cpp M +2 -0 core/utilities/lighttable/lighttablewindow.cpp M +0 -2 core/utilities/lighttable/lighttablewindow_setup.cpp M +2 -2 core/utilities/queuemanager/main/queuemgrwindow.cpp https://invent.kde.org/graphics/digikam/-/commit/3c11e5e55ae021ab180bda270c3b45dd209d816f
The team requested a DebugView output. This is what I get from a simple app start, and then an app close via the typical command bar 'x'. The digikam.exe process remains running, so it was manually stopped via End Task. I saw no activity on the Debug Log during that kill op. Note that I killed any legacy Digikam.exe processes that were active prior to this start/stop cycle. I dont know if additional functions should be invoked etc- presumably, the fact that the process remains running with a simple start/stop is enough to at least show what is active and perhaps what isnt behaving. The only thing I see that seems a bit strange is 369- where I see an ffmpeg entry complaining about 'could not open media', and the error description as 'Immediate exit requested.' I would also note that often, it seems that the EXIF perl tool/process remains active after a shutdown. In this test, I didnt see that (the Exif process did seem to close). R
Created attachment 182276 [details] Debug View Log as requested DebugView log
Hi Roland, Your debug view do not show any special trace where memory can be lost. Anyway, under Linux, I run digiKam in valgrind tool to try to localize where memory can be un-free without success. Here i use a very large collection with Video (MKV, MP4) and Photo (RAW, JPEG, HEIF) and nothing is visible. Face engine is turn on and i use also ExifTool without this dysfunction. Best Gilles Caulier
Hi Im not sure what would be helpful for tracking this down. If it is something that I can make time to do, Im happy to help. Im not a high-level code guy- I do a lot of very low level (assembler/C) work. So my experience with debuggers for high level languages is near zero. What I can tell you is that I opened Dikikam 3 times today, and in checking my task manager in Win10, I have 3 instance (background processes) of 'Advanced digital photo management application' running. Interestingly, one holds 611MB, another 0.4MB, and another 20.5MB. Now, I cannot say if this is where these were on app close- this is end of day for me, and 2 of the 3 runs were done 10-12 hours ago. But, at least it isnt 600MB per as it has been. Regardless, this is 100% repeatable on my system, and where this was an issue some time ago, a fix was implemented and it was gone until a newer version (the much larger install) was released. With that came the return of the problem. Nothing changed on my end; as a developer, I make very few changes to apps, services packs etc on the machine- as these have a tendency to break something in some legacy app etc. I can install it on another machine- and see how it behaves. Perhaps there is some tie to a service pack or a video driver, where presumably- if I copy the physical data/database, and do a clean install (basically mirror the setup)- if that doesnt show the behavior then it has to be related to something specific to the difference between the machines. Both are Win10, both run 32GB RAM on Intel I7 processors, but different motherbords and processor variants, and different video cards/drivers. And likewise, very different support drivers (chipsets, USB3, PCI etc). But if there is a specific debug/trace tool I can run, or if you have a debug build that has some symbols that could help- happy to do what I can to help. Best Roland
Hi digiKam team, same behavior on my side (Windows 11 Pro). I've updated today from 8.6.0 to 8.7.0 and can confirm what Roland described before. After closing the app, I still have "Advanced digital photo management application" running as a background process in Windows task manager. Each time when opening and closing the app, an additional background process "Advanced digital photo management application" appears. With 8.6.0 this is not happening. Best regards Tobias
*** Bug 506775 has been marked as a duplicate of this bug. ***
If you deactivate OpenCL in the digiKam system settings and restart digiKam (only then will the change be applied) can the behavior and memory leak still be reproduced? Maik
Hi Maik At least on my install- no- disabling open CL, closing (end tasking), restarting, validating that CL is not active, and then close the app leaves digiKam running. I still see a 600MB-ish memory leak from it. 0% CPU time once the GUI is closed. Happy to try any other config changes. It is possible that some other service (some EXIF thing etc) remains running when I end task, and so its also possible there is some OpenCL process/service that remains running without a manual end-task or a reboot. No idea- but often stuff is masked as svchost.exe, and its hard to determine what those instances are actually linked to (spawned by etc). Best Rob
*** Bug 507190 has been marked as a duplicate of this bug. ***
Git commit cf700444744fb577a3c2993702372e8de1a0e0cd by Maik Qualmann. Committed on 18/07/2025 at 19:51. Pushed by mqualmann into branch 'master'. cleanup code and fix memory leak add extra debug M +2 -0 core/libs/dnnmodelmanager/dnnmodelmanager.cpp M +2 -0 core/libs/facesengine/recognition/faceclassifier.cpp M +15 -22 core/libs/facesengine/recognition/identityprovider.cpp M +4 -0 core/utilities/facemanagement/backgroundprocesses/facebackgroundrecognition.cpp https://invent.kde.org/graphics/digikam/-/commit/cf700444744fb577a3c2993702372e8de1a0e0cd
Git commit 8b1a755764a22f8373f86baf9fb57208b3fd6225 by Maik Qualmann. Committed on 20/07/2025 at 05:11. Pushed by mqualmann into branch 'master'. for a test make destructor function not private M +3 -2 core/libs/database/utils/ifaces/dio.h M +2 -2 core/libs/dnnmodelmanager/dnnmodelmanager.h M +6 -4 core/libs/facesengine/recognition/faceclassifier.h M +4 -3 core/libs/facesengine/recognition/identityprovider.h M +2 -1 core/utilities/facemanagement/backgroundprocesses/facebackgroundrecognition.h https://invent.kde.org/graphics/digikam/-/commit/8b1a755764a22f8373f86baf9fb57208b3fd6225
Git commit b6fc97ddb108d651db76ba6dba7b8c3802f3296e by Maik Qualmann. Committed on 21/07/2025 at 05:52. Pushed by mqualmann into branch 'master'. according to Qt-Doc, neither constructor nor destructor can be protected or private in Q_GLOBAL_STATIC function M +3 -3 core/libs/database/utils/ifaces/dio.h M +1 -2 core/libs/dnnmodelmanager/dnnmodelmanager.h M +1 -2 core/libs/facesengine/recognition/faceclassifier.h M +1 -2 core/libs/facesengine/recognition/identityprovider.h M +1 -2 core/utilities/facemanagement/backgroundprocesses/facebackgroundrecognition.h https://invent.kde.org/graphics/digikam/-/commit/b6fc97ddb108d651db76ba6dba7b8c3802f3296e
You have right Maik. Great. Link to the doc : https://doc.qt.io/qt-6/qglobalstatic.html#constructor-and-destructor
Yes, but it still seems to work on Linux. I'm not seeing my destructor debug messages on Windows yet. We have many more Q_GLOBAL_STATIC functions whose constructors and destructors we've made private. I can imagine that the destructor has to be called from "outside" at end. Maik
And i'm suprised why Clazy Qt static analyzer do not warm about Q_GLOBAL_STATIC and private/protected destructor. I will take a look.
Maik, look at this: https://github.com/KDE/clazy/blob/master/docs/checks/README-non-pod-global-static.md
Git commit e1f56968d906b547a17292024a2fd382ff5ff83b by Maik Qualmann. Committed on 21/07/2025 at 19:34. Pushed by mqualmann into branch 'master'. make all Q_GLOBAL_STATIC functions public M +5 -5 core/dplugins/generic/tools/mediaserver/server/dmediaservermngr.cpp M +6 -10 core/dplugins/generic/tools/mediaserver/server/dmediaservermngr.h M +5 -5 core/dplugins/generic/tools/mjpegstream/mjpegservermngr.cpp M +8 -11 core/dplugins/generic/tools/mjpegstream/mjpegservermngr.h M +2 -2 core/libs/aitoolspipeline/aitoolspipeline.cpp M +6 -6 core/libs/aitoolspipeline/aitoolspipeline.h M +1 -1 core/libs/album/engine/album.cpp M +9 -8 core/libs/album/engine/albumthumbnailloader.cpp M +5 -8 core/libs/album/engine/albumthumbnailloader.h M +7 -8 core/libs/album/manager/albummanager.cpp M +3 -6 core/libs/album/manager/albummanager.h M +0 -9 core/libs/album/manager/albummanager_p.h M +0 -2 core/libs/database/dbjobs/dbjobsmanager.h M +2 -2 core/libs/database/models/itemsortcollator.cpp M +3 -6 core/libs/database/models/itemsortcollator.h M +2 -2 core/libs/database/server/databaseserverstarter.cpp M +3 -4 core/libs/database/server/databaseserverstarter.h M +5 -5 core/libs/database/tags/tagscache.cpp M +5 -5 core/libs/database/tags/tagscache.h M +5 -5 core/libs/database/utils/ifaces/dio.cpp M +5 -5 core/libs/database/utils/scan/scancontroller.cpp M +3 -5 core/libs/database/utils/scan/scancontroller.h M +6 -4 core/libs/dimg/filters/dimgfiltermanager.cpp M +3 -2 core/libs/dimg/filters/dimgfiltermanager.h M +5 -5 core/libs/dimg/filters/icc/iccsettings.cpp M +3 -3 core/libs/dimg/filters/icc/iccsettings.h M +2 -2 core/libs/dnnmodelmanager/dnnmodelmanager.cpp M +0 -2 core/libs/dnnmodelmanager/dnnmodelmanager.h M +2 -2 core/libs/facesengine/recognition/faceclassifier.cpp M +0 -4 core/libs/facesengine/recognition/faceclassifier.h M +2 -2 core/libs/facesengine/recognition/identityprovider.cpp M +0 -1 core/libs/facesengine/recognition/identityprovider.h M +7 -5 core/libs/fileactionmanager/fileactionmngr.cpp M +3 -4 core/libs/fileactionmanager/fileactionmngr.h M +1 -1 core/libs/iojobs/iojobsmanager.cpp M +2 -3 core/libs/iojobs/iojobsmanager.h M +6 -6 core/libs/metadataengine/dmetadata/dmetadatasettings.cpp M +3 -4 core/libs/metadataengine/dmetadata/dmetadatasettings.h M +6 -6 core/libs/metadataengine/engine/metaenginesettings.cpp M +3 -4 core/libs/metadataengine/engine/metaenginesettings.h M +2 -2 core/libs/networkmanager/networkmanager.cpp M +3 -6 core/libs/networkmanager/networkmanager.h M +5 -5 core/libs/progressmanager/progressmanager.cpp M +8 -9 core/libs/progressmanager/progressmanager.h M +5 -5 core/libs/settings/applicationsettings.cpp M +3 -4 core/libs/settings/applicationsettings.h M +6 -4 core/libs/template/templatemanager.cpp M +5 -6 core/libs/template/templatemanager.h M +5 -5 core/libs/threads/threadmanager.cpp M +3 -7 core/libs/threads/threadmanager.h M +2 -3 core/libs/widgets/mainview/thememanager.h M +6 -6 core/libs/widgets/text/localizesettings.cpp M +3 -4 core/libs/widgets/text/localizesettings.h M +5 -5 core/showfoto/main/showfotosettings.cpp M +3 -4 core/showfoto/main/showfotosettings.h M +4 -2 core/utilities/facemanagement/backgroundprocesses/facebackgroundrecognition.cpp M +0 -2 core/utilities/facemanagement/backgroundprocesses/facebackgroundrecognition.h M +3 -3 core/utilities/facemanagement/pipelines/edit/facepipelineedit.cpp M +3 -2 core/utilities/geolocation/geoiface/core/geoifacecommon.h M +6 -6 core/utilities/geolocation/geoiface/core/geolocationsettings.cpp M +3 -4 core/utilities/geolocation/geoiface/core/geolocationsettings.h M +5 -5 core/utilities/import/main/importsettings.cpp M +3 -5 core/utilities/import/main/importsettings.h M +6 -6 core/utilities/queuemanager/manager/batchtoolsfactory.cpp M +3 -5 core/utilities/queuemanager/manager/batchtoolsfactory.h M +5 -5 core/utilities/queuemanager/manager/workflowmanager.cpp M +3 -6 core/utilities/queuemanager/manager/workflowmanager.h https://invent.kde.org/graphics/digikam/-/commit/e1f56968d906b547a17292024a2fd382ff5ff83b
Git commit c6a5741c99118f1844efada8dc3880bf870d0677 by Maik Qualmann. Committed on 21/07/2025 at 19:44. Pushed by mqualmann into branch 'master'. add more test debug M +2 -0 core/libs/database/models/itemsortcollator.cpp M +10 -0 core/libs/database/utils/scan/scancontroller.cpp M +0 -9 core/libs/database/utils/scan/scancontroller_p.h M +1 -1 core/libs/dnnmodelmanager/dnnmodelmanager.cpp M +1 -1 core/libs/facesengine/recognition/faceclassifier.cpp M +1 -1 core/libs/facesengine/recognition/identityprovider.cpp M +1 -1 core/utilities/facemanagement/backgroundprocesses/facebackgroundrecognition.cpp https://invent.kde.org/graphics/digikam/-/commit/c6a5741c99118f1844efada8dc3880bf870d0677
Git commit 82331cc7e8899ced7a25a0e9a1166798cb9ad10d by Maik Qualmann. Committed on 22/07/2025 at 10:33. Pushed by mqualmann into branch 'master'. add more test debug M +7 -5 core/app/main/digikamapp.cpp M +2 -2 core/app/main/main.cpp https://invent.kde.org/graphics/digikam/-/commit/82331cc7e8899ced7a25a0e9a1166798cb9ad10d
Git commit 4bd723ba1698338744b870e1df6846b35ce6c940 by Maik Qualmann. Committed on 22/07/2025 at 16:56. Pushed by mqualmann into branch 'master'. this will almost certainly fix the hanging digiKam process M +10 -0 core/app/main/digikamapp.cpp M +1 -0 core/app/main/digikamapp_p.h M +1 -1 core/libs/fileactionmanager/fileactionmngr.cpp M +0 -9 core/libs/fileactionmanager/fileactionmngr_p.cpp M +0 -2 core/libs/fileactionmanager/fileactionmngr_p.h M +145 -138 core/libs/fileactionmanager/fileworkeriface.cpp https://invent.kde.org/graphics/digikam/-/commit/4bd723ba1698338744b870e1df6846b35ce6c940
Git commit 4c0be95d20e60e866c45711e8dc54e782f0f85e8 by Maik Qualmann. Committed on 22/07/2025 at 18:52. Pushed by mqualmann into branch 'master'. remove last test debug messages FIXED-IN: 8.8.0 M +1 -1 NEWS M +0 -2 core/libs/dnnmodelmanager/dnnmodelmanager.cpp M +0 -2 core/libs/facesengine/recognition/faceclassifier.cpp M +0 -2 core/libs/facesengine/recognition/identityprovider.cpp M +0 -2 core/utilities/facemanagement/backgroundprocesses/facebackgroundrecognition.cpp https://invent.kde.org/graphics/digikam/-/commit/4c0be95d20e60e866c45711e8dc54e782f0f85e8
Seems to have fixed the problem. Process seems to be terminated, and memory returned to the OS. Ill keep an eye out in case some combo of things leads to a recurrence. Best Roland