Created attachment 115137 [details] Systemmonitor showing how much memory dolphin usese I have several instances of dolphin running, all of them showing two directories using splitview and some of these with at least two tabs. A look into systemmonitor shows that each instance uses at least between 100.000 and 200.000 KByte, the majority around 500.000 and some up to 1 or even 1.5 GB. Why is that and what can be done about it, except killing some of the dolphin instances?
Wow, that's a lot of Dolphins. What are all of these Dolphins showing? Are the directories full of a huge amount of files? What happens if you turn off Previews?
(In reply to Nate Graham from comment #1) > What are all of these Dolphins showing? Are the directories full of a huge > amount of files? Most of them show local directories, but some are connected via sftp to remote servers. In these directories usually there are far less than 100 files and some subdirectories. There are two or so exceptions with in between 500 and 1.000 files and several hundred subdirectories. But these only contain text based files like html and m3u. > What happens if you turn off Previews? Well, preview now is only on for pictures. Until a day or so ago I had it on for PDF and Co., plain text documents and DOC, ODT etc. The letter three I had switched off recently since the icons were only replaced with unreadable text and I did not see anymore what type of document they were. Thus preview seems pretty useless to me. BTW, since I had rebooted my machine this morning all but two dolphins consume around 100 MByte. The two consuming more memory have two and four tabs respectively, whereas the other have only on. It seems that each additional tab consumes about 80 MByte. Anyhow, 80-100 MByte for just showing some icons seems a lot to me. In one case there are only six subdirectories and eight files in one side of the split view window and three more directories in the other side. And all of the files are small text files or sockets and there is now preview shown at all. This dolphin consumes 97.196 K. Incredible.
Thanks for the info.
Interesting is, that the longer my system runs the more memory the dolphins consume. After three days uptime and hibernating the system several times some of them allocate in between 500 MB and more than 1 GB. Freshly started dolphins do not consume that much, but start where the others had started day ago. To me it seems that with every wake-up dolphin allocates additional memory.
One more thing I noticed. After various hibernation cycles some of the dolphins stall. I suppose this is because their data has been shifted to swap. Interestingly, as soon as the respective dolphin gets responsive againthe memory usage jumps up drastically. In some cases they consume several hundred megabytes more memory.
Created attachment 119700 [details] Dolphins consuming huge amounts of memory and CPU time. Any progress on this. Recently my system is almost stalling during to dolphins memory hunger. Have a look at the attached screenshot. No clue what they are doing what they need all this memory for. I would expect that they just display the file tree.
I've got the impression that the situation is getting worse with each system update. Recently several dolphin instances running on may machine use between one and two gigabyte each or even more. Well, in the memory hungry dophins there are several tabs open and all show two directories. Anyhow, I wonder why about 25 directory views use up 2,5 GB after 2 hours of run time, while about 150 tabs in firefox need less than 1,5 GB? Until recently firefox was the program using up the most memory. BTW, it seems that dolphin needs more memory the longer the machine is running and the more files are opened or hovered over. Interestingly, even though meanwhile all previews have been disabled, a library called thumbnail.so starts consuming loads of memory when I hover over files. When I hovered over kdenlive-files it consumed up to 1 GB for a short time.
Does the issue go away or improve at all if you turn off file previews and hide the information panel?
I have also tried to reproduced this over the past few days, but still unable to :/ Currently dolphin uses about 25MB with 10 tabs open showing hundreds of files with previews. But I do not have suspend enabled on my system, so I can't test how it reacts to that, but I will leave it running over night and see if the memory usage increases. If you can narrow down any repro steps it would certainly help us a lot :D
(In reply to Nate Graham from comment #8) > Does the issue go away or improve at all if you turn off file previews and > hide the information panel? All previews were switched off for weeks. Information panel was on but I switched it off now. Have to see, if this brings some improvement. After a restart of the system a couple of minutes ago the dolphin with most tabs open (5) consumes about 90 MB, the ones with only one tab open about 30 MB each and the others something in between. When I started the machine in the morning all dolphins consumed much more. If I recall it right, between 150 MB and 700 MB each. Over the course of the day the memory usage doubled for all dolphins and dropped later to what they had used after starting the system. There is one thing I noticed but I'm not sure if there really is a connection. Because of another bug I had compositing temporally disabled. When I enabled it, it seemed that the memory consumption of the dolphins made a big leap up. BTW, in the moment there are seven dolphins running, four of them have between two and five tabs and all but one or two tabs have two views.
Well, five hours later and after watching a film which was started from one of the dolphins all dolphins are up to memory consumption between about 200 MB and 850 MB. Don't know when the memory usage exactly leaped up, but suppose it happened during the last 2,5 hours when I was watching the film. All previews are off, tool-tips (information panel) are off too, compositing is on. Any other information I could provide?
Just noticed that the dolphin holding the 5 taps made a leap up in memory usage from 850 MB to 1050 MB, which is about 20 %. At a first glance it seems that all dolphins use about 20% more memory now. During the leap they consumed between 5 % and 18 % of CPU time each and a bunch of processes named file.so and one named sftp.so appeared. Now most of these processes disappeared again and CPU time is back down to 1-2 % for at most one dolphin at a time. The rest is zero.
Thanks a lot for all the info! I have been trying to reproduce this issue for some time now and I am not sure I can. But I have been leaving an instance of Dolphin running on my machine for 2 days now, and I can actually see a rise in memory usage. It is not as big as the increase you see but it does use more memory over time. Currently I am at 41MB and 2 days ago it was 25MB and I haven't use the Dolphin instance at all (though I have been using the PC, so it might have something to do with filesystem monitoring). But I will keep digging, and again if you find more exact patterns please post keep posting them :D
I noticed that the number of file.so and sftp.so processes jumps up when the usage of memory increases whereas it is dropping when memory usage decreases. Shortly after reboot there where only two file.so, right now - usage decreasing - five. When dolphins memory usage jumps up and some of the instances use lot of CPU time the number of above mentioned processes goes up to 10-15. BTW, switching off didn't help. Since system boot about ten hours ago and hibernating the system twice memory usage increase do almost 5 GB.
What decoration are you using? Breeze? Just asking because of these detected memory leaks using "valgrind --show-reachable=yes --leak-check=full --trace-children=yes --log-file=dolphin.log dolphin" changed to /tmp and waited 5 minutes: ==6992== 81,920 bytes in 48 blocks are indirectly lost in loss record 2,315 of 2,318 ==6992== at 0x4839F1B: realloc (vg_replace_malloc.c:836) ==6992== by 0x6A8319A: reserve (qdatabuffer_p.h:119) ==6992== by 0x6A8319A: add (qdatabuffer_p.h:98) ==6992== by 0x6A8319A: QBezier::addToPolygon(QDataBuffer<QPointF>&, double) const (qbezier.cpp:182) ==6992== by 0x6B1E28B: QOutlineMapper::curveTo(QPointF const&, QPointF const&, QPointF const&) (qoutlinemapper.cpp:93) ==6992== by 0x6B20357: QOutlineMapper::convertPath(QVectorPath const&) (qoutlinemapper.cpp:168) ==6992== by 0x6B47E50: QRasterPaintEngine::fill(QVectorPath const&, QBrush const&) (qpaintengine_raster.cpp:1834) ==6992== by 0x6B2BF64: QPaintEngineEx::draw(QVectorPath const&) (qpaintengineex.cpp:599) ==6992== by 0x6B2DE62: QPaintEngineEx::drawEllipse(QRectF const&) (qpaintengineex.cpp:831) ==6992== by 0x6B472B2: QRasterPaintEngine::drawEllipse(QRectF const&) (qpaintengine_raster.cpp:3394) ==6992== by 0x6B575F6: QPainter::drawEllipse(QRectF const&) (qpainter.cpp:4265) ==6992== by 0xE096CA2: Breeze::Helper::renderDecorationButton(QPainter*, QRect const&, QColor const&, Breeze::ButtonType, bool) const (breezehelper.cpp:1339) ==6992== by 0xE0B300F: Breeze::Style::titleBarButtonIcon(QStyle::StandardPixmap, QStyleOption const*, QWidget const*) const (breezestyle.cpp:7116) ==6992== by 0xE0B37EA: Breeze::Style::standardIconImplementation(QStyle::StandardPixmap, QStyleOption const*, QWidget const*) const (breezestyle.cpp:1389) ==6992== ==6992== 132,224 bytes in 40 blocks are indirectly lost in loss record 2,316 of 2,318 ==6992== at 0x483780F: malloc (vg_replace_malloc.c:309) ==6992== by 0x692CC47: QImageData::create(QSize const&, QImage::Format) (qimage.cpp:152) ==6992== by 0x692CD4A: QImage::QImage(QSize const&, QImage::Format) (qimage.cpp:772) ==6992== by 0x692CD84: QImage::QImage(int, int, QImage::Format) (qimage.cpp:756) ==6992== by 0x696EE8B: QRasterPlatformPixmap::resize(int, int) (qpixmap_raster.cpp:112) ==6992== by 0x696E328: QPlatformPixmap::create(int, int, QPlatformPixmap::PixelType) (qplatformpixmap.cpp:65) ==6992== by 0x6965536: QPixmap::doInit(int, int, int) (qpixmap.cpp:95) ==6992== by 0x6965632: QPixmap::QPixmap(int, int) (qpixmap.cpp:128) ==6992== by 0xE0B2FAB: Breeze::Style::titleBarButtonIcon(QStyle::StandardPixmap, QStyleOption const*, QWidget const*) const (breezestyle.cpp:7111) ==6992== by 0xE0B37EA: Breeze::Style::standardIconImplementation(QStyle::StandardPixmap, QStyleOption const*, QWidget const*) const (breezestyle.cpp:1389) ==6992== by 0xE0B752C: Breeze::Style::standardIcon(QStyle::StandardPixmap, QStyleOption const*, QWidget const*) const (breezestyle.h:182) ==6992== by 0x63C1D34: QDockWidgetPrivate::updateButtons() (qdockwidget.cpp:737) ==6992== ==6992== 132,224 bytes in 40 blocks are indirectly lost in loss record 2,317 of 2,318 ==6992== at 0x483780F: malloc (vg_replace_malloc.c:309) ==6992== by 0x692CC47: QImageData::create(QSize const&, QImage::Format) (qimage.cpp:152) ==6992== by 0x692CD4A: QImage::QImage(QSize const&, QImage::Format) (qimage.cpp:772) ==6992== by 0x692CD84: QImage::QImage(int, int, QImage::Format) (qimage.cpp:756) ==6992== by 0x696EE8B: QRasterPlatformPixmap::resize(int, int) (qpixmap_raster.cpp:112) ==6992== by 0x696E328: QPlatformPixmap::create(int, int, QPlatformPixmap::PixelType) (qplatformpixmap.cpp:65) ==6992== by 0x6965536: QPixmap::doInit(int, int, int) (qpixmap.cpp:95) ==6992== by 0x6965632: QPixmap::QPixmap(int, int) (qpixmap.cpp:128) ==6992== by 0xE0B2FAB: Breeze::Style::titleBarButtonIcon(QStyle::StandardPixmap, QStyleOption const*, QWidget const*) const (breezestyle.cpp:7111) ==6992== by 0xE0B37EA: Breeze::Style::standardIconImplementation(QStyle::StandardPixmap, QStyleOption const*, QWidget const*) const (breezestyle.cpp:1389) ==6992== by 0xE0B752C: Breeze::Style::standardIcon(QStyle::StandardPixmap, QStyleOption const*, QWidget const*) const (breezestyle.h:182) ==6992== by 0x63C1E43: QDockWidgetPrivate::updateButtons() (qdockwidget.cpp:746) The other memory/cpu eater eater in my case is just fontconfig if I have some local configuration in .fontconfig folder.
(In reply to Jaime Torres from comment #15) > What decoration are you using? Breeze? I use an adapted "Krita - dark". Just changed some of the colors. > The other memory/cpu eater eater in my case is just fontconfig if I have > some local configuration in .fontconfig folder. Are you talking about this folder: ~/.fontconfig/? In this one there are loads of file called like "fe547fea3a41b43a38975d292a2b19c7-le32d4.cache-3" But in my home directory there is one more .fontconfig folder, "~/cache/fontconfig/", also full of files like the one mentioned above. Furthermore there is these files: ~/.JWrapper/JWrapper-Bither/JWrapper-Linux64JRE-00040390989-complete/lib/fontconfig.RedHat.5.bfc ~/.JWrapper/JWrapper-Bither/JWrapper-Linux64JRE-00040390989-complete/lib/fontconfig.RedHat.5.properties.src ~/.JWrapper/JWrapper-Bither/JWrapper-Linux64JRE-00040390989-complete/lib/fontconfig.RedHat.6.bfc ~/.JWrapper/JWrapper-Bither/JWrapper-Linux64JRE-00040390989-complete/lib/fontconfig.RedHat.6.properties.src ~/.JWrapper/JWrapper-Bither/JWrapper-Linux64JRE-00040390989-complete/lib/fontconfig.SuSE.10.bfc ~/.JWrapper/JWrapper-Bither/JWrapper-Linux64JRE-00040390989-complete/lib/fontconfig.SuSE.10.properties.src ~/.JWrapper/JWrapper-Bither/JWrapper-Linux64JRE-00040390989-complete/lib/fontconfig.SuSE.11.bfc ~/.JWrapper/JWrapper-Bither/JWrapper-Linux64JRE-00040390989-complete/lib/fontconfig.SuSE.11.properties.src ~/.JWrapper/JWrapper-Bither/JWrapper-Linux64JRE-00040390989-complete/lib/fontconfig.Turbo.bfc ~/.JWrapper/JWrapper-Bither/JWrapper-Linux64JRE-00040390989-complete/lib/fontconfig.Turbo.properties.src ~/.JWrapper/JWrapper-Bither/JWrapper-Linux64JRE-00040390989-complete/lib/fontconfig.bfc ~/.JWrapper/JWrapper-Bither/JWrapper-Linux64JRE-00040390989-complete/lib/fontconfig.properties.src BTW, I neither use SuSE nor RedHat but had SuSE installed on my system about ten fifteen years ago with KDE 3.x
>> What decoration are you using? Breeze? >I use an adapted "Krita - dark". Just changed some of the colors. It is more important in this case what you have configured in: SystemSettings -> Application Style -> Widget Style : Widget Style. For example: Breeze, CDE, CleanLooks, ... Whitout deleting the .fontconfig folders, just move them to another name, for example: mv .fontconfig fontconfig.testing, if it is possible, outside the plasma session, and see if this makes any difference after restarting plasma and dolphin. If this doesn't have any effect, you can move them back.
I have been running a Dolphin instance with valgrinds massif tool to profile the heap usage and the only large increase I can see is from VLC, so I think this is caused by one of the preview plugins. But I will keep digging...
(In reply to Jaime Torres from comment #17) > >> What decoration are you using? Breeze? > It is more important in this case what you have configured in: > SystemSettings -> Application Style -> Widget Style : Widget Style. For > example: Breeze, CDE, CleanLooks, ... see Screenshots. > Whitout deleting the .fontconfig folders, just move them to another name, > for example: mv .fontconfig fontconfig.testing, if it is possible, outside > the plasma session, and see if this makes any difference after restarting > plasma and dolphin. If this doesn't have any effect, you can move them back. will try this and report later.
Created attachment 119812 [details] Widget Style & Behaviour
Created attachment 119813 [details] Widget Style & Behaviour - Applications
Created attachment 119815 [details] Cinfigure Breeze - General
Created attachment 119816 [details] Cinfigure Breeze - Animation
Created attachment 119817 [details] Cinfigure Breeze - Frames
Created attachment 119818 [details] Cinfigure Breeze - Scrollbars
Created attachment 119819 [details] Cinfigure Breeze - Transparency
(In reply to David Hallas from comment #18) > I have been running a Dolphin instance with valgrinds massif tool to profile > the heap usage and the only large increase I can see is from VLC, so I think > this is caused by one of the preview plugins. I've noticed that VLC is a big memory eater. It seems to load whole films into the RAM while watching them. Anyhow, all previews are switched off, but the information panel is on again, since switching it off did not bring any improvement. But I noticed that hovering over kdenlive-files triggered a library called thumbnail.so that used a lot of CPU time. See Comment 7.
Any progress? For me nothing has changed for the better yet. I even got the impression that it is getting worse. But I noticed one thing: Gwenview also consumes a lot of memory and CPU time, particularly when there are more instances running. Thus I wonder if libraries used in Gwenview are used for preview in Dolphin too and thus might cause the huge memory usage. In many of the directories I explore in Dolphin there are quite a few media files, mostly pictures or videos and sometimes audio files. And is there a way to switch off all previews. That is something I don't really need.
Just noticed something else. After running more or less smoothly Dolphin started running wild when I scrolled a directory that contains a Kdenlive project and various backup files. The project contains a video of about seven minutes.
Hi Knut, sorry, but I haven't made any progress on this (yet). I have tried stressing Dolphin in various ways, but I have been unable to reproduce the issue. I think the main reason may be that I haven't installed kdenlive, or have any kdenlive files, so I think I will try with that and see if it makes a difference. Another thing, have you tested with the latest released Dolphin?
Hi David, (In reply to David Hallas from comment #30) > Another thing, have you tested with the latest released Dolphin? I'm using Dolphin 19.04.3, the latest my distribution - Chakra - offers. This is my setup: Operating System: KDE Plasma Version: 5.16.3 KDE Frameworks Version: 5.60.0 Qt Version: 5.12.4 Kernel Version: 4.19.26-1-CHAKRA OS Type: 64-bit Processors: 4 × Intel® Core™ i5-3317U CPU @ 1.70GHz Memory: 9,6 GiB Swap: 20 GB I noticed one more thing. Dolphin always uses much CPU time when the machine starts swapping. Usually this happens due to Dolphin using more memory for some reason, but sometimes because other programs use up memory. BTW, my system is fully encrypted, all partitions except /boot. And I'm using an 1 TB SSD. And I have one question. Could I somehow provide data about the swapping behavior or other internal processes of Dolphin that might lead to the cause of the problem? If so, how?
(In reply to Knut Hildebrandt from comment #31) > Hi David, > > (In reply to David Hallas from comment #30) > > Another thing, have you tested with the latest released Dolphin? > I'm using Dolphin 19.04.3, the latest my distribution - Chakra - offers. > > This is my setup: > > Operating System: > KDE Plasma Version: 5.16.3 > KDE Frameworks Version: 5.60.0 > Qt Version: 5.12.4 > Kernel Version: 4.19.26-1-CHAKRA > OS Type: 64-bit > Processors: 4 × Intel® Core™ i5-3317U CPU @ 1.70GHz > Memory: 9,6 GiB > Swap: 20 GB > > I noticed one more thing. Dolphin always uses much CPU time when the machine > starts swapping. Usually this happens due to Dolphin using more memory for > some reason, but sometimes because other programs use up memory. > > BTW, my system is fully encrypted, all partitions except /boot. And I'm > using an 1 TB SSD. > > And I have one question. Could I somehow provide data about the swapping > behavior or other internal processes of Dolphin that might lead to the cause > of the problem? If so, how? Hi Knut, thanks for providing info, I am trying to replicate the setup on my local machine, hopefully I will be able to reproduce the problem. I don't know what other info you could provide that would help narrow down the problem, I am still a bit puzzled here :) But, it is super nice that you keep being so responsive on the bug report, that always helps :)
So, this has been happening to me for some time now too. Today, after like 30 hours of uptime, my 3-open-tab Dolphin instance that should use like 40MB was using 3.2GB of RAM. If I restart Dolphin and open KSysGuard, I can see how the memory usage increases at a rate of like 300KB per second for no reason, even with just 1 tab open. This started happening to me in Kubuntu 19.04 after one of the latest upgrades in the Backports PPA (arround June, July or August, I don't know for sure.) It made me ppa-purge the backports one and Dolphin was usable again. Now I've just updated to Kubuntu 19.10 and enabled the Backports PPA straight again, and the issue is happening again. I didn't check if without the PPA happens too, but I bet it does. Just out of curiosity, Knut do you have docker devices in the Devices section? Also I have uninstalled Kdenlive because I don't use it, and the problem persists after restarting Dolphin.
(In reply to Marc González Majoral from comment #33) > Just out of curiosity, Knut do you have docker devices in the Devices > section? don't know, since I do not know what you are talking about. Where do I find the docker devices or the device section respectively? > Also I have uninstalled Kdenlive because I don't use it, and the > problem persists after restarting Dolphin. I don't think this bug is caused by kdenlive. It happens to me even if I do not have any directory with kdenlive files open. BTW, yesterday I made a big system upgrade that came in on Chakra recently. It did not help. Dolphin started with 17MB for one tab in one instance but after a while and adding two more tabs it passed 1 GB. Since it is unusable as it is now I meanwhile have switched back to konqueror. This is my system configuration: KDE Plasma Version: 5.17.1 KDE Frameworks Version: 5.63.0 Qt Version: 5.13.1 Kernel Version: 5.2.11-3-CHAKRA
(In reply to Knut Hildebrandt from comment #34) > (In reply to Marc González Majoral from comment #33) > > Just out of curiosity, Knut do you have docker devices in the Devices > > section? > don't know, since I do not know what you are talking about. Where do I find > the docker devices or the device section respectively? > > > Also I have uninstalled Kdenlive because I don't use it, and the > > problem persists after restarting Dolphin. > I don't think this bug is caused by kdenlive. It happens to me even if I do > not have any directory with kdenlive files open. > > BTW, yesterday I made a big system upgrade that came in on Chakra recently. > It did not help. Dolphin started with 17MB for one tab in one instance but > after a while and adding two more tabs it passed 1 GB. Since it is unusable > as it is now I meanwhile have switched back to konqueror. > > This is my system configuration: > KDE Plasma Version: 5.17.1 > KDE Frameworks Version: 5.63.0 > Qt Version: 5.13.1 > Kernel Version: 5.2.11-3-CHAKRA If you don't know what I'm talking about it's fine, you probably are not using Docker. Was just trying to see if we have something specific in common to help find the cause of the leak. I tried disabling the previews both through the toolbar button and unchecking all the checkboxes in the preferences. I even tried killing the thumbnail.so process just in case. The leak still happens. I of course have to use another file manager too, this is just unusable.
As a last comment, I will say that if I try to manually write something into the location bar (where you can edit the folder path), it constantly gets updated to the current folder, so it's impossible to write anything. Might have something to do with the leak.
(In reply to Marc González Majoral from comment #35) > I tried disabling the previews both through the toolbar button and > unchecking all the checkboxes in the preferences. I even tried killing the > thumbnail.so process just in case. The leak still happens. I do not believe that the previews or even the services are responsible for the leak. It looks to me that konqueror uses the same previews and services. And konquerer runs smooth and without any memory or performance issues.
I am still trying to reproduce this locally, and lately I have been using the excellent Heaptrack (https://milianw.de/blog/heaptrack-a-heap-memory-profiler-for-linux.html) tool to look at Dolphins memory usage, but I still haven't been able to pinpoint any code that keeps consuming memory. The tool reports some minor leaks, but they all appear to be one-off allocations, so they shouldn't cause the heap to grow over time. I was thinking if it would be possible for one of you who is able to reproduce the problem to use the tool to dump what is using memory and share the results here? This page has details and how to clone, build, install and run it: https://milianw.de/blog/heaptrack-a-heap-memory-profiler-for-linux.html
I'm still sad about it but I won't be able to help, this bug was the nail in the coffin that made me switch to another DE after almost 20 years using KDE. What I can say though is that, before giving up, I tried a couple more things, like using Krusader, and the bug also happens there and in the KDialog that appears when, for example, you want to upload a file to a website with the web browser (Chrome in my case). The constant location bar update/rewrite to the current location also happens in those instances, so I'm pretty sure this bug has to do with that constant updating and the filebrowsing library/kpart. Good luck with it, I hope you get it solved because it's a dealbreaker.
(In reply to David Hallas from comment #38) > I am still trying to reproduce this locally, and lately I have been using > the excellent Heaptrack > (https://milianw.de/blog/heaptrack-a-heap-memory-profiler-for-linux.html) > tool to look at Dolphins memory usage, but I still haven't been able to > pinpoint any code that keeps consuming memory. The tool reports some minor > leaks, but they all appear to be one-off allocations, so they shouldn't > cause the heap to grow over time. I was thinking if it would be possible for > one of you who is able to reproduce the problem to use the tool to dump what > is using memory and share the results here? One of my dolphin instances was running under surveillance of heaptrack for almost an hour. I changed directories, enabled/disabled previews, hibernated once, used the search form, let display context menues, copied one file (155 MiB) in split view, deleted the file afterwards and closed one of the views. Dolphin started with ~40 MiB, current memory consumption is ~181 MiB. Heaptracks compressed protocol ist about ~63 MiB. I'm not sure if I'm willing to share the protocol in public since it might contain confidential data (I haven't learned the whatabouts of heaptrack in detail). What kind of result(s) do you want me to share to help your debugging efforts?
Yesterday I created https://bugs.kde.org/show_bug.cgi?id=413939 and today I've noticed this issue. I guess I created a duplicate of this. You may notice that I attached a screenshot of heaptrack on one Dolphin instance in three different times. Maybe somebody can read some useful info from it. I'd say that the issue is somewhere in Qt5 core and notify() function. The interesting information is that this issue appears for me on Krusader too. There are no thumbnails. In few hours the heap can grow to gigabytes. I am very willing to provide any more information/tests if needed.
(In reply to goliash from comment #41) > The interesting information is that this issue appears for me on Krusader > too. There are no thumbnails. In few hours the heap can grow to gigabytes. as I already wrote in comment #28 gwenview also consumes a lot of memory when it is running for a while. Since I do not know much about heaptracks I can't share more information.
*** Bug 413939 has been marked as a duplicate of this bug. ***
Hi, was sent here to share my own experiences. Manjaro KDE, Dolphin 19.08.2. Breath theme, but Breeze is the Application style/widget. I have noticed this problem for the past year. Hardware is an Intel i5-6500 CPU with 32GB RAM and an SSD disk. nvidia proprietary drivers are in use, X11. My workaround is to copy the breadcrumb paths to a new Dolphin window, recreating my tabs and closing the old Dolphin window to free the memory(closing tabs alone does not free anything apparently). Rinse and repeat. The worse case I've experienced was up to around 4GB, may have been more I've not kept track. Usually I notice Dolphin become sluggish(single core/thread of CPU is pegged at 100%) from interactions such as scrolling through the main content pane(jittery/jumpy or low framerate paints, window only, the window itself can be moved smoothly with kwin wobbly window effect no issue). Changing tabs, closing tabs, right click context menu on the breadcrumb location for copying, all of these I recall inducing the 100% CPU core load for several seconds(length of delay depends on memory consumption, can be closer to 10 seconds). I believe with the recent 19.08 applications update, dockers overlayfs mounts began appearing again for some reason. I only mention this because someone else here asked about Docker, their visibility is probably a regression that should be raised in another bug report and unrelated to this issue. I've experienced it without running the Docker daemon. Probably the time I noticed it the most active was when I had about 5 tabs in one window open, rarely interacting with them, but doing heavy editing of some files(fontconfig specifically). At one point, I may have been actively deleting files(cache) that I believe one tab covered. The deletion iirc was via CLI, but Dolphin would visibly update to represent files being added/removed if I had that tab open. I recall this iterative approach generating 20-40-ish files each time I modified/saved my font config files, I'd clear the generated cache, and open up a web browser(firefox) which would rebuild the cache, or if the cache existed add about 9 items(1 per process I think). Must have gone through thousands of those cache files. Someone brought up Gwenview. In the past I would "disable" a display(dual monitor setup), without physically powering it off, but as it's DVI connection, it couldn't be done via software command either, so I fullscreened an solid black image with Gwenview. Usually because it was at night and I wanted to watch something on Netflix without the other display being distracting. I can't recall how long it'd take, few hours to a day perhaps, but Gwenview responsiveness at leaving the fullscreen state would be very slow(10 second or so). So the other commenter may be onto something related there as both Dolphin and Gwenview are likely to share some KDE Frameworks lib? While the active development and file tree updates example above with fontconfig might sound like it's related only to that sort of activity. I've left a Dolphin window open/idle and gone to sleep, 8 hours later 1GB more of memory was allocated to it. I've also witnessed via ksysguard Dolphin memory climbing over the course of an hour, but I don't recall it being constant or a fixed amount(not that I properly measured this). All I know is it can grow with no interaction, but file updates/refreshes may be worth looking into? As for my typical usage, I usually only use one virtual desktop, but sometimes I do use multiple, I've not done any observations if that makes any difference. I tend to have one or two windows open, especially if I use multiple virtual desktops, tabs average 3-5, rarely more than that per window. Tabs are usually project directories(developer), or downloads directory(I don't download that much, but I haven't been housekeeping(currently it states 14 folders, 97 files, 71MB). Baloo is enabled(I've also noticed high CPU activity recently when using the default search feature, no new results for some time but the CPU usage remained at 100% for a full core until I closed the search, KFind tends to work better for me and doesn't exhibit issues like that). I also use sftp in Dolphin for accessing a remote server, Kate may be open with some files from that which were opened via Dolphin(usually drag/drop from Dolphin to Kate). Current Dolphin window is at 1.2GB and has been fairly steady on that with 3 tabs. The most active tab in that window would be the sftp one. Been open for a day or so, on virtual desktop 3 atm, and most of my activity has been with Chrome and Kate(editing some remote files). I'm a little surprised as it seems a bit more tame in memory usage/growth. Perhaps another possibility could be when the browser, steam or a torrent program is performing a download over multiple hours(8Mbit connection), and a tab is open like "Downloads" having it's metadata updated frequently as the transfer progresses? I have switched off previews in Dolphin as of late, possibly after the fontconfig work where I frequently recall having frustration with this issue. Info panel is still there, so perhaps you're onto something about that being the main cause of memory growth. At 1.2GB for the current window mentioned, there is about a 500-1000ms delay changing tabs and context menu on breadcrumbs(it became faster to respond after the first right click), scrolling is fine for the file tree(tree view, some folders expanded, states 18 folders 61 files for the sftp tab) , it's mostly fine scrolling up/down repeatedly on the left panel with my list of places, remote, devices(includes two docker overlay items atm) and removable devices, but occasionally freezes for a moment before jumping to the scroll position, it continues to switch between smooth and not updating to mouse/scroll position for about a second(just noticed this seems to happen based on the horizontal position of the cursor, absolutely fine if dragging over the left pane, but crossing over the scrollbar element is what hits high CPU load on a core/thread at around 80% briefly).
Latest news: At least on my system an increase in memory consumption (both in dolphin and gwenview) is reliably provokable by mounting or unmounting something. A systemd automounter showed me the way: Every time a network share of my NAS gets mounted (a defined idle timeout leads to unmounting later and hence reoccuring mounts), the memory consumption goes up. It's not restricted to network shares, the same applies to mounting or unmounting a local USB stick. Copying files/directories between directories or storage devices shows no effect. So it doesn't seem to be the change in available data but the change in the directory tree / mount points.
Kate has the same problem if the file system module is activated. My guess is that this bug is related to NFS. It is really annoying. Several times I 'forgot' my Krusader/Dolphin, now even Kate, opened and I run out of memory so I had to restart my PC :-(
I have another observation. The heap grows much slower when my IDEA (Jetbrains) is turned off. After few days without IDEA running in background my Krusader/Dolphin are still with reasonable heap size. My guess is that IDEA watches the filesystem for any changes and this causes that Qt applications are notified about something too but probably they do not release the memory from the heap.
(In reply to goliash from comment #47) > I have another observation. The heap grows much slower when my IDEA > (Jetbrains) is turned off. After few days without IDEA running in background > my Krusader/Dolphin are still with reasonable heap size. Just was wondering what IDEA is and after a short search I'm sure it can't be the cause of the problem in my case. Can't remember having it installed. Or does it come along with other stuff? > My guess is that IDEA watches the filesystem for any changes and this causes > that Qt applications are notified about something too but probably they do > not release the memory from the heap. But why konquerer, which is Qt too, is not affected?
I do not think I am able to answer your questions. It is just an observation on my system. I was quite surprised that the issue was not reproducible for me anymore and the only difference is that I turned off my IDE which is IDEA before Christmas to keep out of work :-)
Hi! Same problem. Dolphin eat RAM (all my 16 GB). But when I stopped docker service, dolphin stops eat RAM. How can we fix it? Dolphin 19.12.2
(In reply to Andrei Ivnitskii from comment #50) > Same problem. Dolphin eat RAM (all my 16 GB). But when I stopped docker > service, dolphin stops eat RAM. How can we fix it? How do I stop docker service and how do I find out if it is running in the first place? There is no such thing in the dolphin settings as much as I can tell.
Could be fixed by: https://phabricator.kde.org/D27002 > This leak presented itself by steadily growing memory > use while something still > unknown triggered solid's onMtabChanged excessively. > If that's also the case for the reporter of that bug, > this should've made a big difference, otherwise only a small one. ! > The output of heaptrack would tell for sure.
Knut Hildebrandt, do you have docker installed? If yes, try sudo systemctl stop docker
(In reply to Andrei Ivnitskii from comment #53) > Knut Hildebrandt, do you have docker installed? If yes, try sudo systemctl > stop docker To be honest, I do not even know what docker is. Tried stopping it anyway: $ sudo systemctl stop docker Failed to stop docker.service: Unit docker.service not loaded. Thus I suppose docker is not responsible for this bug in my case.
May be. But in my case docker is a reason of dolphin memory leak
(In reply to Postix from comment #52) > Could be fixed by: https://phabricator.kde.org/D27002 Does this mean, this is the fix and once it finds it's way into dolphins code base the leak is goen? For which dolphin release the fix is planned?
The commit from comment 56 will be available in KIO version 5.68.0. Expected release date is March 14th.
(In reply to Christoph Feck from comment #57) > The commit from comment 56 will be available in KIO version 5.68.0. Expected > release date is March 14th. Great, looking forward to it :-)
This bug is fixed for me after KDE Frameworks 5.68 has landed in KDE Neon.
Not fixed here. Every time a mount or unmount occurs, memory consumption of running dolphin processes goes up by typically more than 200 K. With several automounters using idle timeouts for NAS exports and several running dolphins this sums up quite fast. As told in https://bugs.kde.org/show_bug.cgi?id=398908#c45, this is not specific to the NAS exports (NFS) but can be provoked identically by mounting and unmounting a USB flash drive. Plasma 5.18.3, Frameworks 5.68.0, Qt 5.14.1, Kernel 5.5.8.
Hello, I'm providing dump of HeapTrack: https://drive.google.com/open?id=13Rve1v38d9ud0d5I9UjA6amHtUVPQVtM The other interesting this is that basically Dolphin becomes unusable at this point. It have high cpu usage and needs 10-20 seconds to render things like hover, directory change and etc. It have CPU TIME+: https://i.imgur.com/bYTeKio.png And btw - same memory leak happens on Kate.
And btw I have same installation with same distro on desktop PC - I don't have that problem there.
Weighing in here with another "me too". We use Plasma 5 with latest KDE and latest Dolphin on a VM at work. The VM has 8 NFS4 shares permanently mounted. If we leave a Dolphin window open overnight, the memory usage creeps up from approx 500mb used to 32GB (100%) and other applications and services start crashing due to lack of memory. While the memory usage is climbing, the CPU usage also gradually increases from 1% to 100% usage, and stays at 100% usage until I close all open Dolphin windows. On a different VM with no NFS mounts, this problem does not occur. We were having the same problem with Kate, but after disabling the "Filesystem" plugin, the problem no longer occurs with Kate. Note, we do also have Docker installed, others suggested it might be a culprit but I don't think it is related in this case. We disabled the docker daemon overnight one time and the problem with Dolphin still occurred.
Not fixed for me too. Used KDE Frameworks 5.68 from Kubuntu 20.04, but when I run docker dolphin starts to eat RAM
Please help, I need idea how to fix it.
Yeah, I fixed it. I recompiled libKF5Solid.so.5.68.0 and cancelled this patch https://phabricator.kde.org/D22080 Without it docker overlays don't show in the dolphin and dolphin stops eat RAM
This Bug is still present in Plasma 5.18.5 and KDE Frameworks 5.70. I tried what Andrei suggested, I built a modified libKF5Solid with the overlays feature removed, and then opened Dolphin to leave it running for 48 hours over the weekend. Unfortunately in my case, it did not fix it. The Dolphin process grew to over 7.8GB memory used, and 100% (of one core) CPU usage for at least the last 24 hours. I believe in this case it is not related to Docker overlays, but more likely related to the multiple NFS4 mounts on the system. I have a different VM with same Ubuntu OS and very similar software stack, it has only one (different) NFS4 mount, and it is not affected by this bug.
Same here. Arch linux, Plasma 5.18.5 and KDE Frameworks 5.70. Dolphin memory consumption increased to 1.7GB over two days. Increased CPU usage I don't see though. I don't use SMB or NFS.
Hi, I can reproduce this consistently when running docker images - rate is approximately 1MB every 3-5 seconds. I compiled dolphin (latest master, commit: f6afbbc2401cdd2e722e2ea5d3ad59b960370433) with debug symbols (and also installed the most referenced qt/kde libs with debug symbols) and ran heaptrack - capture available here: https://drive.google.com/file/d/1WdcK45LEhChvgfRhAz6Q3lxOAbOc-ahO/view?usp=sharing The biggest culprit appears to be: https://i.imgur.com/NOcsTBn.png Callstack here: https://i.imgur.com/nop70QU.png Does this suggest it's not a dolphin memory issue, but related to libKF5DBusAddons?
Also affected by this on multiple machines running Kubuntu. I also suspect mounts here (docker overlay, Linux nsfs, ...) which get created frequently when building docker images and starting/stopping docker containers and more so with docker-compose setups.
Seems to be resolved for me. I have the following: KDE Plasma 5.19.3 KDE Frameworks 5.72 Qt 5.15 Kernel 5.4.52-1-MANJARO Dolphin 20.04.3 Not sure when exactly, but I don't recall having major memory issues with Dolphin over the past few months. My Docker usage or other remote/external mounting activity isn't that high lately, but I have been using a Docker container(no docker-compose) recently with local directory and file volume mounts that I restart quite a few times during the day. I've also had up remote system over SFTP and browsed that a bit. Other than that, presently a single window with 7 tabs open and tree view with nested locations opened with lists of images. Only 88MB and about 4 days uptime(window has been around longer via session restore). I think I last recall the problem in April/May, I don't think 20.04 release of Dolphin fixed it, nor 5.18 of Plasma, so it might have been a newer Frameworks release that was the last piece needed? I only updated to Plasma 5.19 a few days ago, and don't recall recent memory issues before then with Dolphin either. If someone has a simple test they'd like me to run I guess I can give that a go to further verify?
One thing I have been doing but still haven't configured as a default, is increase the systems file watchers. They kept running out recently when working on a larger project, and GitKraken would also complain about running out of file watchers sometimes. A recent update didn't complain when I would have expected it to, and despite being idle was constantly causing 50% CPU usage(2 cores/threads on 4 cores/threads i5-6500) as well as notably more memory usage, although it was growing from around 1.2GB to 1.6GB then falling back to 1.2GB consistently. If my system versions don't resolve the problem for you, or your distro isn't able to use those easily, perhaps try this(only changes until reboot): sudo sysctl fs.inotify.max_user_watches=262144 The number is 2^18, your distro may be using 2^13(8192) or lower by default. You can check with(use before running above command): cat /proc/sys/fs/inotify/max_user_watches
This bug tracker could really do with the ability to edit comments. Sorry for the additional notification. Forgot to mention that increasing file watchers resolved the GitKraken issue(which would not resolve otherwise, had tried killing the process and starting it again which had the same symptoms until watchers were increased).
Didn't post here for a while because I was using Chakra - not Kubuntu as somehow is stated in the header - and did not get updates for a year or so. That's why I eventually switched to Manjaro and situation seems to have improved a lot. Nevertheless dolphin is still accumulating memory over time. But it now also releases memory once in a while and tends to get back to memory consumption of less than 100 MB per dolphin instance. And I noticed one interesting thing. If I hibernate - suspend to disk - the laptop memory usage drops to around 20 or even less per instance, Unfortunately after wake-up all instances get very busy and memory usage at least the last time was back to something between 150 and 500 MB each within seconds. BTW, in Comnment4 and Comnment5 I wrote that the situation worsened after hibernating the laptop. That is not true. It should have written after suspending (to RAM). Sorry for the confusion. Sytem details: Operating System: Manjaro Linux KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2 Kernel Version: 5.10.7-3-MANJARO OS Type: 64-bit Processors: 4 × Intel® Core™ i5-3317U CPU @ 1.70GHz Memory: 9.6 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4000 These are the dolphin related processes running at the moment: dolphin -> 7 with up to 10 Tabs each and all Tabs with 2 views file.so -> 17 http.so -> 3 sftp.so -> 1
I'll just quote from a post I made elsewhere a week or so ago. Though it's been going on for months. The freeze when saving --- from every browser --- is what concerns me most, though having to kill dolphin instances every few hours is tedious in the extreme. > Dolphin's getting worse recently. Slow as hell, memory gobbling [*], and can suddenly disappear. The rest of the applications on my KDE PCLinuxOS are fast and stable. Plus [ Dolphin ] takes ages to set up to be useful: like a side tree view panel: one needs the 'Folders' view, not the Places, or Information; Show Menu Bar and Split View --- which are all things hidden from a new user. For finding things it is so useless I have to fire up Double Commander or Krusader. . , Worst of all, saving an image from any browser freezes, then takes half a minute each. I mostly switched to other contrivances like an image downloader or DownLoadThemAll!, even at the last saving from Page Info... . I always said Konqueror was an indifferent browser, but a great file-manager. Never understood why they switched from that. < . [*] Some dolphins -- seems to depend on the different 'virtual desktop' I rather imagine --- go up to 500MB after an hour. . Old AMD Phenom computer, B50 CPU, 16 GB RAM KDE 5.80.0 Plasma 5.21.3 --- although this has persisted through different KDE/Plasma versions. . Nota Bene: Sadly Firefox uses the GTK file chooser [ I am using Pale Moon mostly = old Firefox ] and whilst I like/need this layout, I strongly depreciate having any Gnome elements on my computer. Not as bad as Brave though, that installs dozens of other unkillable little Gnome GVfs CPU gobblers...
Right click in the left panel and click "Hide Section Remote" seems have fixed it for me. Otherwise there's a roughly 300kb increase in memory usage every minute.
(In reply to GSC from comment #76) > Right click in the left panel and click "Hide Section Remote" seems have > fixed it for me. Otherwise there's a roughly 300kb increase in memory usage > every minute. This seems to slow down the increase in memory usage, but it still happens in some instances. Only remedy: hibernating (suspend to disk) the system. Then memory usage is reduced to below 100 MB, sometimes as little as about 10 MB, per instance. But it increases again after a while. I noticed another interesting thing. Memory usage increases a lot if there is activity in views which contain big files. Last night I watched a movie which was about 700 MB big. After watching it I noticed that the dolphin with the view of the folder containing the respective file used more than 500 MB. Same with another dolphin. I had saved several files of about 300 to 500 MB to one of the folders I had open in it. I did not open these files, but renamed them. The memory usage of respective dolphin rose up to 150-200 MB.
I narrowed it down even more than Knut Hildebrandt: Huge jump in ram usage happens instantly when I open big files(e.g movies) with double-click or by Enter. Ram does not increase at all if instead I open a file with right-click and manually select `Open with XYZ`. Dolphin Version 20.12.3 KDE Frameworks 5.81.0 Qt 5.15.2 (built against 5.15.2)
I'm having the same issue. It began right after upgrading to 20.12.3-r1 (current stable version on Gentoo Linux amd64). (In reply to J.D from comment #78) > I narrowed it down even more than Knut Hildebrandt: > Huge jump in ram usage happens instantly when I open big files(e.g movies) > with double-click or by Enter. Ram does not increase at all if instead I > open a file with right-click and manually select `Open with XYZ`. I can reproduce this as follows: - open Dolphin -> RAM usage ~25MB - click on ISO image -> Ark opens up, RAM usage of Dolphin jumps to ~550MB - right-click -> Open with Ark -> RAM usage stays at ~25MB I thinks it's worth mentioning that yesterday, when I noticed this, three Dolphin instances were consuming ~5GB and plasmashell at the same time was also consuming large amounts of RAM (~2GB). Maybe this is related somehow. Hopefully this gets fixed soon, with Dolphin being such an important part of everyday KDE use. Operating System: Gentoo Linux KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.80.0 Qt Version: 5.15.2 Kernel Version: 5.10.27-gentoo OS Type: 64-bit Processors: 12 × AMD Ryzen 5 2600X Six-Core Processor Memory: 15,6 GiB of RAM Graphics Processor: GeForce RTX 2060 SUPER/PCIe/SSE2
Forgot to mention that I'm using neither Docker nor NFS.
Created attachment 137954 [details] Heaptrack 1 - start, open large file, exit (In reply to Fonic from comment #79) > (In reply to J.D from comment #78) > > I narrowed it down even more than Knut Hildebrandt: > > Huge jump in ram usage happens instantly when I open big files(e.g movies) > > with double-click or by Enter. Ram does not increase at all if instead I > > open a file with right-click and manually select `Open with XYZ`. > > I can reproduce this as follows: > - open Dolphin -> RAM usage ~25MB > - click on ISO image -> Ark opens up, RAM usage of Dolphin jumps to ~550MB > - right-click -> Open with Ark -> RAM usage stays at ~25MB I ran heaptracks for this scenario, hope it helps debugging this. For each of those heaptracks, Dolphin was started, file was opened, Dolphin was closed. Memory consumption seems to be directly related to size of file (see heaptrack file names).
Created attachment 137955 [details] Heaptrack 2 - start, open large file, exit
I am also experiencing this issue. Memory usage jumps to 550MB if I open a large file by clicking it, and not if I open through the menu. Nice detective work. This seems like a very specific issue. Should it perhaps go in its own bug report? Arch Linux Dolphin 20.12.3 Frameworks 5.81
There are at least two problems here. a) when we try to determine the mimetype of a file it runs through MimeTypeFinderJob which effectively calls ::get() on the backing KIO worker, that function then sends the mimetype and starts reading the file. This is problematic because it reads data we never need, wasting energy on entirely pointless data copying from disk to worker memory, to socket, to client memory. In case throughput is large enough (which it can easily be with e.g. nvme drives) this effectively reads the entire file into memory while mimetype reading is going on, causing a **temporary** spike in consumption. This is fairly horrible and really needs to be changed for the sake of the planet. b) Something then gets confused and doesn't detect the memory getting freed. I say confused because according to the heaptrack recording of comment #82 the actual user space heap returns to 10mib. I do however definitely see the smaps file in /proc reporting a much larger heap. My theory here is that this actually is connected to a). The way I understand it the TransferJob inside the MimeTypeFinderJob would get discarded when the MimeTypeFinderJob finishes. My theory is that this then leads to the socket that was talking to the worker to have dangling data in kernel space. i.e. the socket has pending data that we'll never (?) read. I'll move the bug to KIO for further inspection. My recommendation would be to split mimetype detection away form ::get() and then see where we are at. Chances are this fixes b) implicitly because the kio worker wouldn't keep streaming useless data that can get stuck in the pipes.
Just had Dolphin using 1GB of memory with a few tabs open and 1 day uptime. Dolphin version 21.04.0. I have an information panel open but no terminal or anything. I don't recall doing anything unusual, but I'll keep an eye on it.
https://invent.kde.org/frameworks/kio/-/merge_requests/444
This bug report is actually two bugs, one of them that the mimetype finding code was falling back to KIO::get() which, as sitter's investigation shows, meant the whole file was read into memory which meant spikes in memory consumption used by Dolphin; hopefully this is fixed by the MR I linked above. (Note that the issue with the code in MimeTypeFinderJob was probably the same in OpenUrlJob, because that code lived in OpenUrlJob before getting split to a separate MimeTypeFinderJob). Now the other issue, the original report seems to hint that some of the files in question are on remote filesystems?
Git commit c19876052ecec18a87a82f5950e8909e22e895ba by David Faure, on behalf of Ahmad Samir. Committed on 13/05/2021 at 23:15. Pushed by dfaure into branch 'master'. MimeTypeFinderJob: the StatJob details should include the mimetype Apparently we forgot to specify that we want the UDS_MIME_TYPE field in the statFile() method (both when it lived in OpenUrlJob and when it was moved to MimeTypeFinderJob). And now there is a dedicated StatJob flag, StatMimeType, that we can use. Not passing KIO::StatMimeType when creating the StatJob meant the code always used a get job to determine the mime type, which mean that e.g. opening an ISO file from Dolphin, which supposedly just needs to launch Ark, had the whole file read into memory, which means that opening a couple of ISO's and you're out of memory... Thanks to sitter for doing a big chunk of the investigative work in the bug report. M +5 -1 src/core/mimetypefinderjob.cpp https://invent.kde.org/frameworks/kio/commit/c19876052ecec18a87a82f5950e8909e22e895ba
Great that this got sorted out, many thanks! It seems, however, that the patch is incompatible with KIO's 5.80 codebase and KIO can't be updated individually without updating all KDE packages due to dependencies, or am I missing something?
That reminds me, I should let distro maintainer know about this patch to backport it to 5.82. (About 5.80, the KUbuntu maintainers can rebase the patch manually?)
*** Bug 436505 has been marked as a duplicate of this bug. ***
*** Bug 427168 has been marked as a duplicate of this bug. ***
I must say, I have noticed a massive improvement on this and Dolphin no longer soaks up excessive memory. So enormous thanks to those who achieved this.
I still observe Dolphin memory leak with plasma-framework 5.83.0: in just two days memory usage of running dolphin instance increased from ~210 MB to ~740 MB RSS There must be something else.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
The problem still prevails and somehow I got the impression that it is getting worse again. Last night I had to shut down my laptop since it was getting very slow due to endless swapping. Dolphin was consuming about 3.5 GB at that moment. Operating System: Manjaro Linux KDE Plasma Version: 5.21.5 KDE Frameworks Version: 5.82.0 Qt Version: 5.15.2 Kernel Version: 5.10.42-1-MANJARO Processors: 4 × Intel® Core™ i5-3317U CPU @ 1.70GHz Memory: 9.6 GiB of RAM
The bug was fixed for 5.83, you are still on 5.82.
(In reply to Harald Sitter from comment #97) > The bug was fixed for 5.83, you are still on 5.82. Sorry, then I'll check again when the respective update is offered.
Updated KDE Frameworks and nothing seems to have changed. I even got the impression it got worse. Hibernated the machine last night, what brought all dolphin instances back to below 100 MB each, but now about three hours later three of them are in between 0.5 and 1 GB, four between 100 and 500 MB and only two below 100 MB. And Ooe of the ones above 500 MB sometimes uses between 10 and 15% CPU. BTW, the more CPU time an instance has accumulated the higher the memory it occupies. I still double click all files - including video and audio - to open them. Only exceptions: audio playlists which I open from amarok and if I do not want to open a file in it's standard application. One change I noticed, sometimes memory seems to get released. But if I'm not mistaken, this effect I already noticed earlier, for instance with Frameworks 5.82.0. Operating System: Manjaro Linux KDE Gear Version: 21.04.3 KDE Plasma Version: 5.22.3 KDE Frameworks Version: 5.84.0 Qt Version: 5.15.2 Kernel Version: 5.10.49-1-MANJARO (64-bit) Graphics Platform: X11
Is that actually the same defect though? When you start from a new dolphin and click a super large file, like say an ISO, does the consumption jump up and stay high even after the file is fully opened?
(In reply to Harald Sitter from comment #100) Sorry for the late reply, I was out of town for a while. > Is that actually the same defect though? I do not know, but it at least the same behavior I described in my first bug report. All dolphin instances use up more and more memory over time, particularly if the system has been suspended or hibernated various times. > When you start from a new dolphin and click a super large file, like say an > ISO, does the consumption jump up and stay high even after the file is fully > opened? Just restarted the machine after having to shut it down since dolphin used up to 4 GB of memory. After the restart I opened an extra instance an started a 3.2 GB movie. When I started the movie the respective dolphin instance used at bit more than 20 MB and slowly gained 10 MB until the movie finished. Meanwhile some of the other dolphin instances had gained more than 100 MB each. The ones showing the highest memory usage at the same time show the highest CPU time - up to 3:50 over two hours - too, whereas the one I used to start the movie only has 0:21. Maybe I should mention that all instances showing high memory usage and CPU time have several tabs and split view, only the one opened to start the movie has a single tab and simple view. Well, I got the impression that my description of the behavior does not help to narrow down the problem. What data could be more helpful and how can I retrieve it? Operating System: Manjaro Linux KDE Plasma Version: 5.22.4 KDE Frameworks Version: 5.84.0 Qt Version: 5.15.2 Kernel Version: 5.10.56-1-MANJARO (64-bit) Graphics Platform: X11
Just noticed that there is a correlation between the number of tabs and views open in a dolphin instance and the CPU time and memory it is accumulating. After only about six hours of total run time the situation looks like this: 1. 9 tabs x 2 views -> 326 MB 2. 8 tabs x 2 views -> 215 MB 3. 6 tabs x 2 views -> 208 MB 4. 4 tabs x 2 views -> 160 MB 5. 2 tabs x 2 views -> 101 MB 6. 2 tabs x 2 views -> 99 MB 7. 1 tabs x 2 views -> 66 MB 8. 1 tabs x 1 views -> 46 MB Most of the time I was watching movies, answering emails or surfing the internet and not using any of the dolphins. Some I did not touch at all but even though they are not used they accumulate memory over time.
Back with a short summery of my observations. 1. with the moment of its start a dolphin instance begins to constantly allocate memory 2. the amount of memory allocated as well as the CPU time used correlates with the number of tabs and views open and grows over time 3. the memory allocation does not depend on user interaction. Opening files several GB big does not cause any jump in memory usage. On the other hand the memory usage increases constantly even without any user interaction at all. 4. hibernating the machine brings the used memory down to about 20 to 30 MB for each instance, but within minutes, sometimes seconds, it is back to the level before hibernation and than further rising 5. over time and with many dolphins, tabs and views open not only the dolphin instances get very slow but the machine too, due to constant swapping For me there arise a few questions: 1. why does dolphin constantly allocate memory even though there is no user interaction? 2. what does dolphin need the saved data for, since it obviously works well with memory usage far below 100 MB even if there are many tabs open? 3. Why once allocated memory never gets freed? All the data I mention here I gathered in KSysGuard. I've no idea what tools I have to use to collect more useful data. One last thing. The original title of the bug report was something like "Dolphin uses huge amounts of memory" and has been changed since a potential memory leak has been identified. Since this bug was fixed the bug report has been closed even though the problem I reported three years ago still exists. Thus I'd propose to reopen the bug and change it's title back to the original one.
I agree with Knut Hildebrandt The original bug which was reported, the one which I am experiencing, and commented on (#63), is not fixed. A _different_ memory leak was found, and fixed, (changing the title of this bug to reflect that was a nice touch) but the bug matching the description of the original report is not fixed.
First step -> reopen.
(In reply to Knut Hildebrandt from comment #103) > Back with a short summery of my observations. > > 1. with the moment of its start a dolphin instance begins to constantly > allocate memory > 2. the amount of memory allocated as well as the CPU time used correlates > with the number of tabs and views open and grows over time > 3. the memory allocation does not depend on user interaction. Opening files > several GB big does not cause any jump in memory usage. On the other hand > the memory usage increases constantly even without any user interaction at > all. > 4. hibernating the machine brings the used memory down to about 20 to 30 MB > for each instance, but within minutes, sometimes seconds, it is back to the > level before hibernation and than further rising > 5. over time and with many dolphins, tabs and views open not only the > dolphin instances get very slow but the machine too, due to constant swapping > > For me there arise a few questions: > > 1. why does dolphin constantly allocate memory even though there is no user > interaction? > 2. what does dolphin need the saved data for, since it obviously works well > with memory usage far below 100 MB even if there are many tabs open? > 3. Why once allocated memory never gets freed? > > All the data I mention here I gathered in KSysGuard. I've no idea what tools > I have to use to collect more useful data. > > One last thing. The original title of the bug report was something like > "Dolphin uses huge amounts of memory" and has been changed since a potential > memory leak has been identified. Since this bug was fixed the bug report has > been closed even though the problem I reported three years ago still exists. > Thus I'd propose to reopen the bug and change it's title back to the > original one. valgrind would be nice to use to check for memory leak. `valgrind dolphin` would suffice to learn a Does closing tabs or views release memory? To some extent dolphin will always use more memories for each tab and views, since each need an independent KCoreDirLister, that is a cache to read and access the filesystem and enrich the data, and those will use proportionally memory as the directory they access are big. We still have room for optimization for sure.
Created attachment 145772 [details] Dolphin v 21.12.1 running for half a day, leaked about 1 GiB. I've tried to record heaptrack of running Dolphin v 21.12.1 from Arch linux repos for half a day. Result is in `heaptrack.dolphin.1030819_19.zst`. Dolphin leaked about 1GiB of RAM. I am not quite skilled to analyze this recording. Seems to be caused by numerous KDirWatch and KBookmarkManager invocations. Should I re-record heaptrack on dolphin with debug symbols? Will it yield more useful data?
Created attachment 145797 [details] Dolphin v 21.12.1 with debug symbols, leaked about half a GiB. Suggests something is wrong near KBookmarkManager or KDirWatch I've recorded another heaptrack ( heaptrack.dolphin.1113185_19.zst ), now for dolphin with debug symbols. It still suggests something is wrong related to KBookmarkManager or KDirWatch. Probably this is partially triggered by my large bookmarks file: $ wc ~/.local/share/user-places.xbel 8297 10501 251857 /home/self/.local/share/user-places.xbel Some entries are related to lots tags I have on my files (like `tags:/python`). Some entries are to long gone sshfs mounts. I probably can figure out something from here.
(In reply to Alexander Meshcheryakov from comment #108) > Created attachment 145797 [details] > Dolphin v 21.12.1 with debug symbols, leaked about half a GiB. Suggests > something is wrong near KBookmarkManager or KDirWatch > > I've recorded another heaptrack ( heaptrack.dolphin.1113185_19.zst ), now > for dolphin with debug symbols. > > It still suggests something is wrong related to KBookmarkManager or > KDirWatch. > > Probably this is partially triggered by my large bookmarks file: > > > $ wc ~/.local/share/user-places.xbel > 8297 10501 251857 /home/self/.local/share/user-places.xbel > > Some entries are related to lots tags I have on my files (like > `tags:/python`). Some entries are to long gone sshfs mounts. I probably can > figure out something from here. It is missing the solid debug symbols it seems, to help further track down the origin of the over memory allocation. The heaptrack trace is great clue to fix this, hope you can make a new one with the solid debug symbols as well.
And kio debug symbols.
Alexander Meshcheryakov, Do you use encrypted devices ?
OK, I'll try to record with kio and solid with debug symbols. I do use encryption. In my setup LVM logical volumes are encrypted with LUKS.
Here too, my system also is encrypted. All partitions reside in a LUKS encrypted LVM2 volume. Interestingly, I opened this bug about three months after encrypting my system. No clue if the problem existed before, but I doubt it since I would have reported it earlier ;-)
(In reply to Alexander Meshcheryakov from comment #112) > OK, I'll try to record with kio and solid with debug symbols. Thank you, this should allow to go to the bottom of it for now the traces are nebulous. > > I do use encryption. In my setup LVM logical volumes are encrypted with LUKS. I have a suspicion this is part of the bug origin.
Created attachment 146198 [details] Dolphin v 21.12.1 leaked ~800MB, dolphin, dolphin, kio and solid have debug symbols I've recorded one more heaptrack trace "heaptrack.dolphin.1944565_19.zst". Now with solid and kio debug symbols.
Thank you Alexander Meshcheryakov , traces are of great quality. It confirms my hypothesis, the leak seem to happen whenever solid is asked to get the filepath of a luks encrypted udisk2 mount. I could not figure out precisely the leak origin. It seems to happen in Solid::Backends::UDisk2::Device::Device when called from Solid::Backends::UDisk2::StorageAccess::clearTextPath() The connection there seem to not be cleaned after the short-lived Device is deleted, but I am not sure of my interpretation as it does not make much sense. I have this patch that should help, although I can't guarantee it: diff --git src/solid/devices/backends/udisks2/udisksstorageaccess.cpp src/solid/devices/backends/udisks2/udisksstorageaccess.cpp index 389832b..da1dbcc 100644 --- src/solid/devices/backends/udisks2/udisksstorageaccess.cpp +++ src/solid/devices/backends/udisks2/udisksstorageaccess.cpp @@ -6,6 +6,7 @@ */ #include "udisksstorageaccess.h" +#include "udisksdevicebackend.h" #include "udisks2.h" #include "udisks_debug.h" @@ -376,9 +377,9 @@ QString StorageAccess::clearTextPath() const QDomElement nodeElem = nodeList.item(i).toElement(); if (!nodeElem.isNull() && nodeElem.hasAttribute("name")) { const QString udi = prefix + "/" + nodeElem.attribute("name"); - Device holderDevice(udi); + DeviceBackend* backend = DeviceBackend::backendForUDI(udi); - if (m_device->udi() == holderDevice.prop("CryptoBackingDevice").value<QDBusObjectPath>().path()) { + if (m_device->udi() == backend->property("CryptoBackingDevice").value<QDBusObjectPath>().path()) { // qDebug() << Q_FUNC_INFO << "CLEARTEXT device path: " << udi; return udi; } I could not test it as I am not sure how to setup an environment to trigger the bug. So Alexander Meshcheryakov or someone else affected, feel free to compile and install solid with this to test.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/solid/-/merge_requests/77
Méven Car I've rebuilt solid with your patch and after 3 days of running Dolphin uses just about 450 MB of RAM. This is a huge improvement, thank you! I hope this patch gets merged. I've made some more observations though that indicate that there are parts of this issue that are still are not fixed. I'll come back when gather my recollections.
I have noticed that memory leaks are happening not gradually but in sharp spikes. During such spikes Dolphin consumes about 70% of a single CPU core. I have not figured out the trigger of such moments. Sometimes leaks happen even while user session is locked, and as far as I can tell there are no updates in content of directories which Dolphin displays. But it seems leaks happen more often when I interact with my PC. The patch from #c116 does not remove these CPU usage spikes. But with patched solid instead of leaking ~200 MB at a time, Dolphin leaks just 5-20 MB. Here is some data: Obligatory heaptrack of Dolphin running for 3 days with solid patched from #c116 http://45.86.162.4/files/2022/heaptrack.dolphin.solid_patch_116.19.zst CPU and RSS consumption graphs for Dolphin with patched solid http://45.86.162.4/images/2022/dolphin_patched_solid_cpu.png http://45.86.162.4/images/2022/dolphin_patched_solid_rss.png Here are the graphs for Dolphin with unpatched solid http://45.86.162.4/images/2022/dolphin_cpu_2.png http://45.86.162.4/images/2022/dolphin_rss_2.png Note how memory leaks are simultaneous with CPU spikes. From all these observations I am rather confident that the core issue is not an inefficiency of StorageAccess::clearTextPath which is fixed by Méven Car patch, but rather mysterious spurious ~2 min intensive process related to KDirWatch. I suppose this process does not do anything useful and should be disabled/optimized. Also this process seems to be related to filesystem tags (user.xdg.tags in xattrs). If I remove /home/self/.local/share/user-places.xbel at the moment it gets populated with tags:/ again Dolphin leaks.
Sometimes during intensive operation leading to memory leak Dolphin spews out thousands of messages "QString::contains: invalid QRegularExpression object" in console output. Once I got almost 128K of these messages in 137 seconds. I have no idea how to track down where do they come from.
The QRegularExpression related messages, either it's from the filter bar (which appears at the bottom of the view with Ctrl+i), or from the search bar (which appears under the toolbar with Ctrl+f). Were you using either of these tools? (I think we need to check the QRegularExpression object before calling QString::contains() in this case, since we're dealing with interactive input, which can have regex syntax errors).
I do not remember consciously calling either search bar, or filter bar in past months. And I definitely have not put regular expressions in these tools.
Testing dolphin briefly, it's not the filter bar, it's the search bar that's using regex (it interprets the input as a regex).
(In reply to Alexander Meshcheryakov from comment #122) > I do not remember consciously calling either search bar, or filter bar in > past months. And I definitely have not put regular expressions in these > tools. All my dolphin instances have the filter bar open all the time. It is used quite regularly. The search bar I do not use that often. Anyhow, I did not notice any surge in CPU and memory use when using them.
Git commit 5d2b5180fc4d1737f12cbbaba12884dbae832823 by Méven Car, on behalf of Méven Car. Committed on 17/02/2022 at 11:30. Pushed by meven into branch 'master'. Don’t create a full Solid::Device to check encryption M +3 -2 src/solid/devices/backends/udisks2/udisksstorageaccess.cpp https://invent.kde.org/frameworks/solid/commit/5d2b5180fc4d1737f12cbbaba12884dbae832823
Git commit 1d7cceda76bd3a1c2c4060d7c215ff6cbae64769 by Nate Graham. Committed on 04/03/2022 at 18:50. Pushed by ngraham into branch 'master'. Revert "Don’t create a full Solid::Device to check encryption" This reverts commit 5d2b5180fc4d1737f12cbbaba12884dbae832823. This commit regressed mounting LUKS volumes; we will have to find a better way. Related: bug 451105 M +2 -3 src/solid/devices/backends/udisks2/udisksstorageaccess.cpp https://invent.kde.org/frameworks/solid/commit/1d7cceda76bd3a1c2c4060d7c215ff6cbae64769
I also have the same issue with Dolphin v19.12.3: - KDE Frameworks 5.68.0 - Qt 5.12.8 (built against 5.12.8) - Kubuntu 20.04.4 LTS I only have one window open and it's already using 8,067,952 KB of heap (yes, 8 GB)
(In reply to konfilios from comment #127) > I also have the same issue with Dolphin v19.12.3: > - KDE Frameworks 5.68.0 > - Qt 5.12.8 (built against 5.12.8) > - Kubuntu 20.04.4 LTS > > I only have one window open and it's already using 8,067,952 KB of heap > (yes, 8 GB) Kubuntu 22.04.1 LTS has been released. Would you update and retry your tests?
Wow, the problem seems to be solved. Has there been some work on this issue recently? I'm right now using: Operating System: Manjaro Linux KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 Kernel Version: 5.10.148-1-MANJARO (64-bit) Graphics Platform: X11 Anyhow, I did not notice the change after a Plasma, frameworks of Gear update but after an update that included a bunch of other packages including the kernel. No clue which of them brought the change, but maybe the kernel update did the job. At some point there was a discussion that the problem might be caused by encrypting file systems. Here the list of all packages that were included in the update in question: [2022-10-10T22:37:07+0200] [ALPM] upgraded cairomm (1.14.3-2 -> 1.14.4-1) [2022-10-10T22:37:07+0200] [ALPM] upgraded xz (5.2.6-1 -> 5.2.7-1) [2022-10-10T22:37:08+0200] [ALPM] upgraded lib32-glibc (2.36-4.0 -> 2.36-5) [2022-10-10T22:37:08+0200] [ALPM] upgraded libbpf (0.8.1-1 -> 1.0.1-1) [2022-10-10T22:37:08+0200] [ALPM] upgraded iproute2 (5.19.0-1 -> 6.0.0-1) [2022-10-10T22:37:08+0200] [ALPM] upgraded dhclient (4.4.3-3 -> 4.4.3.P1-1) [2022-10-10T22:37:08+0200] [ALPM] upgraded f2fs-tools (1.15.0-1 -> 1.15.0-2) [2022-10-10T22:37:09+0200] [ALPM] upgraded foomatic-db (3:20220328-1 -> 3:20221004-1) [2022-10-10T22:37:09+0200] [ALPM] upgraded foomatic-db-nonfree (3:20220328-1 -> 3:20221004-1) [2022-10-10T22:37:09+0200] [ALPM] upgraded foomatic-db-nonfree-ppds (3:20220328-1 -> 3:20221004-1) [2022-10-10T22:37:10+0200] [ALPM] upgraded foomatic-db-ppds (3:20220328-1 -> 3:20221004-1) [2022-10-10T22:37:10+0200] [ALPM] upgraded hwdata (0.362-2 -> 0.363-1) [2022-10-10T22:37:10+0200] [ALPM] upgraded game-devices-udev (0.17-1 -> 0.18-1) [2022-10-10T22:37:11+0200] [ALPM] upgraded git (2.37.3-1 -> 2.38.0-1) [2022-10-10T22:37:11+0200] [ALPM] upgraded pango (1:1.50.10-1 -> 1:1.50.11-1) [2022-10-10T22:37:12+0200] [ALPM] upgraded xkeyboard-config (2.36+89+g382c5feb-1 -> 2.37-1) [2022-10-10T22:37:12+0200] [ALPM] upgraded gspell (1.10.0-2 -> 1.12.0-1) [2022-10-10T22:37:12+0200] [ALPM] upgraded lib32-pango (1:1.50.10-1 -> 1:1.50.11-1) [2022-10-10T22:37:12+0200] [ALPM] upgraded lib32-xz (5.2.6-1 -> 5.2.7-1) [2022-10-10T22:37:12+0200] [ALPM] upgraded libcdio (2.1.0-2 -> 2.1.0-3) [2022-10-10T22:37:12+0200] [ALPM] upgraded libimagequant (4.0.1-1 -> 4.0.4-1) [2022-10-10T22:37:12+0200] [ALPM] upgraded libmediainfo (22.06-1 -> 22.09-1) [2022-10-10T22:37:12+0200] [ALPM] upgraded libupnp (1.14.13-1 -> 1.14.14-1) [2022-10-10T22:37:15+0200] [ALPM] upgraded linux510 (5.10.146-1 -> 5.10.147-1) [2022-10-10T22:37:15+0200] [ALPM] upgraded linux510-virtualbox-host-modules (6.1.38-7 -> 6.1.38-8) [2022-10-10T22:37:25+0200] [ALPM-SCRIPTLET] In order to use the new version, reload all virtualbox modules manually. [2022-10-10T22:37:28+0200] [ALPM] upgraded linux54 (5.4.215-1 -> 5.4.217-1) [2022-10-10T22:37:28+0200] [ALPM] upgraded linux54-virtualbox-host-modules (6.1.38-5 -> 6.1.38-7) [2022-10-10T22:37:39+0200] [ALPM-SCRIPTLET] In order to use the new version, reload all virtualbox modules manually. [2022-10-10T22:37:39+0200] [ALPM] upgraded mediainfo (22.06-2 -> 22.09-1) [2022-10-10T22:37:39+0200] [ALPM] upgraded mhwd-nvidia-390xx (390.154-1 -> 390.154-2) [2022-10-10T22:37:39+0200] [ALPM] upgraded mhwd-nvidia-470xx (470.141.03-1 -> 470.141.03-2) [2022-10-10T22:37:39+0200] [ALPM] upgraded mkvtoolnix-cli (70.0.0-2 -> 70.0.0-3) [2022-10-10T22:37:39+0200] [ALPM] upgraded mkvtoolnix-gui (70.0.0-2 -> 70.0.0-3) [2022-10-10T22:37:39+0200] [ALPM] upgraded numactl (2.0.15-1 -> 2.0.16-1) [2022-10-10T22:37:39+0200] [ALPM] upgraded pacman (6.0.1-15 -> 6.0.2-1) [2022-10-10T22:37:39+0200] [ALPM] upgraded octopi (0.13.0-2 -> 0.14.0-1) [2022-10-10T22:37:39+0200] [ALPM] upgraded octopi-notifier-qt5 (0.13.0-2 -> 0.14.0-1) [2022-10-10T22:37:43+0200] [ALPM] upgraded opera (91.0.4516.20-1 -> 91.0.4516.65-1) [2022-10-10T22:37:43+0200] [ALPM] upgraded opera-ffmpeg-codecs (104.0.5112.102-1 -> 105.0.5195.127-1) [2022-10-10T22:37:43+0200] [ALPM] upgraded pangomm (2.46.2-1 -> 2.46.3-1) [2022-10-10T22:37:43+0200] [ALPM] upgraded perl-alien-build (2.70-1 -> 2.71-1) [2022-10-10T22:37:43+0200] [ALPM] upgraded perl-xml-libxml (2.0207-3 -> 2.0208-1) [2022-10-10T22:37:43+0200] [ALPM] upgraded python-rich (12.5.1-1 -> 12.6.0-1) [2022-10-10T22:37:43+0200] [ALPM] upgraded python-setuptools (1:63.0.0-1 -> 1:63.2.0-1) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-common (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-audio-alsa (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-audio-dbus (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-audio-jack (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-audio-oss (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-audio-pa (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-audio-sdl (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-ui-opengl (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-ui-spice-core (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-audio-spice (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-block-curl (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-block-dmg (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-block-nfs (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-block-ssh (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-chardev-spice (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-hw-display-qxl (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-hw-display-virtio-gpu (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-hw-display-virtio-gpu-gl (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-hw-display-virtio-gpu-pci (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-hw-display-virtio-gpu-pci-gl (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-hw-display-virtio-vga (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:43+0200] [ALPM] upgraded qemu-hw-display-virtio-vga-gl (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:44+0200] [ALPM] upgraded qemu-hw-s390x-virtio-gpu-ccw (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:44+0200] [ALPM] upgraded qemu-hw-usb-host (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:44+0200] [ALPM] upgraded qemu-hw-usb-redirect (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:44+0200] [ALPM] upgraded qemu-hw-usb-smartcard (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:44+0200] [ALPM] upgraded qemu-img (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:44+0200] [ALPM] upgraded qemu-pr-helper (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:44+0200] [ALPM] upgraded qemu-system-x86-firmware (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:44+0200] [ALPM] upgraded qemu-system-x86 (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:44+0200] [ALPM] upgraded qemu-tools (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:44+0200] [ALPM] upgraded qemu-ui-curses (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:44+0200] [ALPM] upgraded qemu-ui-dbus (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:44+0200] [ALPM] upgraded qemu-ui-egl-headless (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:44+0200] [ALPM] upgraded qemu-ui-gtk (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:44+0200] [ALPM] upgraded qemu-ui-sdl (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:44+0200] [ALPM] upgraded qemu-ui-spice-app (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:44+0200] [ALPM] upgraded qemu-vhost-user-gpu (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:44+0200] [ALPM] upgraded qemu-virtiofsd (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:44+0200] [ALPM] upgraded qemu-desktop (7.1.0-6 -> 7.1.0-8) [2022-10-10T22:37:45+0200] [ALPM] upgraded rubygems (3.3.21-1 -> 3.3.21-2) [2022-10-10T22:37:45+0200] [ALPM] upgraded ruby-abbrev (0.1.0-1 -> 0.1.0-3) [2022-10-10T22:37:45+0200] [ALPM] upgraded ruby-base64 (0.1.1-1 -> 0.1.1-3) [2022-10-10T22:37:46+0200] [ALPM] upgraded ruby-benchmark (0.2.0-1 -> 0.2.0-3) [2022-10-10T22:37:46+0200] [ALPM] upgraded ruby-bigdecimal (3.1.2-1 -> 3.1.2-3) [2022-10-10T22:37:46+0200] [ALPM] upgraded ruby-bundler (2.3.22-1 -> 2.3.22-2) [2022-10-10T22:37:46+0200] [ALPM] upgraded ruby-cgi (0.3.2-1 -> 0.3.2-9) [2022-10-10T22:37:46+0200] [ALPM] upgraded ruby-csv (3.2.5-1 -> 3.2.5-3) [2022-10-10T22:37:46+0200] [ALPM] upgraded ruby-date (3.2.2-1 -> 3.2.2-3) [2022-10-10T22:37:46+0200] [ALPM] upgraded ruby-delegate (0.2.0-1 -> 0.2.0-3) [2022-10-10T22:37:47+0200] [ALPM] upgraded ruby-did_you_mean (1.6.1-1 -> 1.6.1-3) [2022-10-10T22:37:47+0200] [ALPM] upgraded ruby-digest (3.1.0-1 -> 3.1.0-5) [2022-10-10T22:37:47+0200] [ALPM] upgraded ruby-drb (2.1.0-1 -> 2.1.0-4) [2022-10-10T22:37:47+0200] [ALPM] upgraded ruby-english (0.7.1-1 -> 0.7.1-3) [2022-10-10T22:37:47+0200] [ALPM] upgraded ruby-erb (2.2.3-2 -> 2.2.3-4) [2022-10-10T22:37:47+0200] [ALPM] upgraded ruby-etc (1.3.0-2 -> 1.3.0-5) [2022-10-10T22:37:47+0200] [ALPM] upgraded ruby-fcntl (1.0.1-1 -> 1.0.1-3) [2022-10-10T22:37:47+0200] [ALPM] upgraded ruby-fiddle (1.1.0-1 -> 1.1.0-3) [2022-10-10T22:37:47+0200] [ALPM] upgraded ruby-fileutils (1.6.0-1 -> 1.6.0-3) [2022-10-10T22:37:47+0200] [ALPM] upgraded ruby-find (0.1.1-1 -> 0.1.1-3) [2022-10-10T22:37:47+0200] [ALPM] upgraded ruby-forwardable (1.3.2-1 -> 1.3.2-5) [2022-10-10T22:37:47+0200] [ALPM] upgraded ruby-getoptlong (0.1.1-1 -> 0.1.1-2) [2022-10-10T22:37:47+0200] [ALPM] upgraded ruby-io-console (0.5.11-1 -> 0.5.11-2) [2022-10-10T22:37:47+0200] [ALPM] upgraded ruby-io-nonblock (0.1.0-1 -> 0.1.0-2) [2022-10-10T22:37:47+0200] [ALPM] upgraded ruby-io-wait (0.2.3-1 -> 0.2.3-3) [2022-10-10T22:37:47+0200] [ALPM] upgraded ruby-ipaddr (1.2.4-1 -> 1.2.4-2) [2022-10-10T22:37:47+0200] [ALPM] upgraded ruby-reline (0.3.1-1 -> 0.3.1-2) [2022-10-10T22:37:47+0200] [ALPM] upgraded ruby-irb (1.4.1-1 -> 1.4.1-2) [2022-10-10T22:37:48+0200] [ALPM] upgraded ruby-json (2.6.2-1 -> 2.6.2-2) [2022-10-10T22:37:48+0200] [ALPM] upgraded ruby-logger (1.5.1-1 -> 1.5.1-2) [2022-10-10T22:37:48+0200] [ALPM] upgraded ruby-mutex_m (0.1.1-1 -> 0.1.1-2) [2022-10-10T22:37:48+0200] [ALPM] upgraded ruby-uri (0.11.0-2 -> 0.11.0-5) [2022-10-10T22:37:48+0200] [ALPM] upgraded ruby-net-http (0.2.2-1 -> 0.2.2-2) [2022-10-10T22:37:48+0200] [ALPM] upgraded ruby-stringio (3.0.2-1 -> 3.0.2-4) [2022-10-10T22:37:48+0200] [ALPM] upgraded ruby-time (0.2.0-2 -> 0.2.0-4) [2022-10-10T22:37:48+0200] [ALPM] upgraded ruby-open-uri (0.2.0-2 -> 0.2.0-3) [2022-10-10T22:37:48+0200] [ALPM] upgraded ruby-psych (4.0.4-2 -> 4.0.4-4) [2022-10-10T22:37:48+0200] [ALPM] installed ruby-racc (1.6.0-3) [2022-10-10T22:37:48+0200] [ALPM] upgraded ruby-rdoc (6.4.0-2 -> 6.4.0-4) [2022-10-10T22:37:48+0200] [ALPM] upgraded ruby-tmpdir (0.1.2-1 -> 0.1.2-3) [2022-10-10T22:37:48+0200] [ALPM] upgraded ruby-stdlib (3.0.4-9 -> 3.0.4-18) [2022-10-10T22:37:49+0200] [ALPM] upgraded ruby-test-unit (3.5.3-1 -> 3.5.4-1) [2022-10-10T22:37:49+0200] [ALPM] upgraded ruby-bundledgems (3.0.4-9 -> 3.0.4-18) [2022-10-10T22:37:49+0200] [ALPM] upgraded ruby (3.0.4-9 -> 3.0.4-18) [2022-10-10T22:37:55+0200] [ALPM] upgraded signal-desktop (5.61.1-1 -> 5.62.0-1) [2022-10-10T22:37:58+0200] [ALPM] upgraded vlc (3.0.17.4-8 -> 3.0.17.4-9)
(In reply to Knut Hildebrandt from comment #129) > Wow, the problem seems to be solved. Has there been some work on this issue > recently? I'm right now using: > > Operating System: Manjaro Linux > KDE Plasma Version: 5.25.5 > KDE Frameworks Version: 5.98.0 > Qt Version: 5.15.6 > Kernel Version: 5.10.148-1-MANJARO (64-bit) > Graphics Platform: X11 > > Anyhow, I did not notice the change after a Plasma, frameworks of Gear > update but after an update that included a bunch of other packages including > the kernel. No clue which of them brought the change, but maybe the kernel > update did the job. At some point there was a discussion that the problem > might be caused by encrypting file systems. Here the list of all packages > that were included in the update in question: > Did you reboot after this upgrade but not after the plasma/frameworks one ? This bug could be fixed indirectly by a framework change or a Qt change, less likely anything eles changed this.
Don't understand the question. I reboot the machine once in a while. Anyhow kernel updates only a applied after a reboot. Until this the system is still using the old kernel.