Bug 392133 - Huge memory consumption while doing nothing
Summary: Huge memory consumption while doing nothing
Status: RESOLVED UPSTREAM
Alias: None
Product: krusader
Classification: Applications
Component: general (show other bugs)
Version: 2.7.2
Platform: Kubuntu Linux
: NOR major
Target Milestone: ---
Assignee: Krusader Bugs Distribution List
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2018-03-21 11:41 UTC by Piotr Dobrogost
Modified: 2021-10-28 17:51 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
log from running Krusader under Valgrind (105.28 KB, application/zip)
2018-05-25 12:34 UTC, Piotr Dobrogost
Details
Detailed memory information for Krusader 2.7.0 reported by KDE System Monitor (165.20 KB, text/plain)
2018-05-30 07:15 UTC, Piotr Dobrogost
Details
Detailed memory information for Krusader (git version, under Kubuntu 18.04) reported by KDE System Monitor (1.53 KB, text/plain)
2018-08-25 18:34 UTC, Toni Asensi Esteve
Details
The output of `heaptrack_print` for krusader process which consumed 1.9GB of memory (478.62 KB, text/plain)
2018-12-18 08:35 UTC, Piotr Dobrogost
Details
heaptrack.krusader.jpg (1.05 MB, image/jpeg)
2021-09-04 21:03 UTC, PhobosK
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Piotr Dobrogost 2018-03-21 11:41:53 UTC
I noticed that after I open archive file (viewing as a directory) Krusader is leaking memory till the system stalls (at this moment it has eaten about 4GB of memory).
I open mainly zip and tar archives.
Comment 1 Nikita Melnichenko 2018-03-22 07:21:06 UTC
Can't repro on git version. Can you try and report back? If it's still reproducible, please write specific repro steps. Thanks!

BTW, if you try Dolphin + krarc, do you experience memory problems too?
Comment 2 Martin Kostolný 2018-03-22 07:35:39 UTC
Also, please provide following info (if you can):
1) example archive(s) that are causing the memory leak
2) how many of them has to be opened in parallel to cause a considerable memory leak?
3) which process is leaking? "krusader" or "kio_krarc.so"? The latter one actually handles archives.

Thanks!
Comment 3 Piotr Dobrogost 2018-03-23 07:41:54 UTC
(In reply to Nikita Melnichenko from comment #1)
> 
> BTW, if you try Dolphin + krarc, do you experience memory problems too?

Will try and report back.

(In reply to Martin Kostolný from comment #2)
> Also, please provide following info (if you can):
> 1) example archive(s) that are causing the memory leak
> 2) how many of them has to be opened in parallel to cause a considerable
> memory leak?
> 3) which process is leaking? "krusader" or "kio_krarc.so"? The latter one
> actually handles archives.

Left one Python .egg file (it's zip format) opened in Krusader for a night and in result Krusader takes 2GB of memory and kio_krarc takes 900MB of memory. After closing file (changing directory) Krusader still takes 2GB and kio_krarc is gone. Will try to reproduce with some publicly available archive and will report back.
Comment 4 Piotr Dobrogost 2018-04-13 07:46:08 UTC
I retract my previous statement that the leak is due to opening archive file – sorry for confusion.
The leak does occur consistently and without any action; it's enough to start Krusader and leave it alone.
I'm going to run it under valgrind with the following options and post results:

valgrind --leak-check=full \
         --show-leak-kinds=all \
         --track-origins=yes \
         --verbose \
         --log-file=/tmp/valgrind-krusader.log \
         krusader

If you have any suggestion as to what I can do more to help find the culprit please let me know.

Krusader 2.6.0
KDE Frameworks 5.44.0
Qt 5.10.1
Fedora 28
Comment 5 Nikita Melnichenko 2018-04-15 04:40:41 UTC
Interesting. Do you have any activities that update files in the folders that you have opened in Krusader? If you close all tabs except one on each panel and set their paths to '/', does leak happen? I don't recall any other potential reasons that may cause Krusader actively doing something and eat memory.
Comment 6 Nikita Melnichenko 2018-05-21 06:45:40 UTC
Resolving due to lack of response.
Comment 7 Piotr Dobrogost 2018-05-25 12:34:36 UTC
Created attachment 112859 [details]
log from running Krusader under Valgrind

(In reply to Nikita Melnichenko from comment #6)

> Resolving due to lack of response.
Sorry for not getting back to You earlier.

Please see attached log from running Krusader under Valgrind. Krusader has been running for a few hours (no actions in Krusader were performed during this time) and reached about 1.1Gb of consumed memory.
Comment 8 Nikita Melnichenko 2018-05-26 06:04:09 UTC
Valgrind report doesn't show any Gb of leaks, only some Kb.

Please answer my previous questions and try running under a brand new user. I also encourage you to upgrade to v2.7.
Comment 9 Piotr Dobrogost 2018-05-30 07:15:04 UTC
Created attachment 112963 [details]
Detailed memory information for Krusader 2.7.0 reported by KDE System Monitor

(In reply to Nikita Melnichenko from comment #8)
> Valgrind report doesn't show any Gb of leaks, only some Kb.

I have no idea why doesn't Valgrind show this. Please see attached information on Krusader's memory usage taken from KDE System Monitor – "The process krusader (with pid 2242) is using approximately 1.8 GB of memory." This is after about 24 hours of running.
 
(In reply to Nikita Melnichenko from comment #5)
> Interesting. Do you have any activities that update files in the folders
> that you have opened in Krusader?

No.

(In reply to Nikita Melnichenko from comment #5)
> If you close all tabs except one on each
> panel and set their paths to '/', does leak happen?

Yes.

(In reply to Nikita Melnichenko from comment #8)
> Please answer my previous questions and try running under a brand new user.

I'll run under a brand new user as you suggested and will report back but no earlier than in 3 weeks due to vacations.

(In reply to Nikita Melnichenko from comment #8)
> I also encourage you to upgrade to v2.7.

I did as soon as this version was available in Fedora's rpm repos however the problem still remains. The attached memory report is for version 2.7.0.


Krusader 2.7.0
KDE Plasma 5.12.5
KDE Frameworks 5.46.0
Qt 5.10.1
Fedora 28
Comment 10 Piotr Dobrogost 2018-07-10 08:23:58 UTC
> (In reply to Nikita Melnichenko from comment #8)
> > Please answer my previous questions and try running under a brand new user.

I answered your questions in comment 9.
I've run Krusader under a brand new user for about 15 hours and it took about 1.2GB of memory.

What can I do more to help you find out why does it leak memory?

Krusader 2.7.0
KDE Plasma 5.13.1
KDE Frameworks 5.47.0
Qt 5.10.1
Fedora 28
Comment 11 Nikita Melnichenko 2018-07-11 05:45:42 UTC
Thanks for reaching back after trying on the latest stable. This is very weird issue since nobody else experience anything similar.

Since valgrind is not showing leaks, it's most likely not a leak. Krusader allocates resources for something it needs. Question is, what does it need?

Could you please run `krusader -d` in the same setting (fresh user, tabs at '/') and attach here?
Another thing to try is `strace krusader` but the output might be big.

I assume you know how to redirect stdout and stderr to file (2>&1 >file).
Comment 12 Toni Asensi Esteve 2018-08-11 11:52:14 UTC
To further investigate this issue, KDE developers need the information
requested in comment #11. If you can't provide it, or need help with finding that
information, please add a comment.
Comment 13 Piotr Dobrogost 2018-08-14 07:45:00 UTC
(In reply to Nikita Melnichenko from comment #11)
> 
> Could you please run `krusader -d` in the same setting (fresh user, tabs at
> '/') and attach here?

[piotr@demon]~% krusader -d 2>&1 | tee ~/krusader.log
11:02:33.486-warning default unknown@0 # QWidget::insertAction: Attempt to insert null action
11:02:33.490-warning default unknown@0 # QWidget::insertAction: Attempt to insert null action
11:02:37.119-warning default unknown@0 # Unable to find icon "inode-socket" of size QSize(22, 22) in any configured theme
11:47:47.324-warning default unknown@0 # UdevQt: unhandled device action "unbind"
11:50:57.598-warning default unknown@0 # UdevQt: unhandled device action "bind"
13:23:05.762-warning default unknown@0 # UdevQt: unhandled device action "unbind"
09:33:30.182-warning default unknown@0 # UdevQt: unhandled device action "bind"

This is whole output after running Krusader about 24 hours. At the end it occupied 1.7GB of memory.
"unhandled device action" warning is generated each time I connect or disconnect my Nexus 5X phone to USB port.
Comment 14 Toni Asensi Esteve 2018-08-25 18:32:42 UTC
Using Kubuntu 18.04 the problem is not happening, it looks like it does not really depend on Krusader. I'll attach a "Detailed memory information for Krusader (git version, under Kubuntu 18.04) reported by KDE System Monitor".

Maybe Piotr could compile and execute a very reduced version of Krusader, to see if the same problem keeps happening.
Comment 15 Toni Asensi Esteve 2018-08-25 18:34:38 UTC
Created attachment 114602 [details]
Detailed memory information for Krusader (git version, under Kubuntu 18.04) reported by KDE System Monitor
Comment 16 Andrew Crouthamel 2018-09-28 03:28:00 UTC
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 set the bug status 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!
Comment 17 Piotr Dobrogost 2018-09-28 07:25:30 UTC
Requested information was submitted in comment 13; changing status accordingly.
Comment 18 Toni Asensi Esteve 2018-09-28 11:44:10 UTC
As far as we know, the problem is not happening to Krusader developers, and nobody has reported a bug about this issue.

As it was suggested previously, maybe Piotr could compile and execute a very reduced version of Krusader, to see if the same problem keeps happening.
Comment 19 Nikita Melnichenko 2018-11-15 06:47:03 UTC
I checked your logs again - it appears memory problem is coming from heap, i.e. allocated by the app itself for some reason.

Can you try tools like heaptrack (http://milianw.de/blog/heaptrack-a-heap-memory-profiler-for-linux, PEAK MEMORY CONSUMERS) or massif and let us know? Thanks!
Comment 20 Bug Janitor Service 2018-11-30 03:45:48 UTC
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!
Comment 21 Piotr Dobrogost 2018-12-13 10:43:57 UTC
(In reply to Nikita Melnichenko from comment #19)
> 
> Can you try tools like heaptrack
> (http://milianw.de/blog/heaptrack-a-heap-memory-profiler-for-linux, PEAK
> MEMORY CONSUMERS) or massif and let us know? Thanks!

Now I run Krusader through heaptrack all the time but memory consumption is fairly normal (in the range 100MB-300MB) . As soon as it shows up I will post heaptrack stats.
Comment 22 Piotr Dobrogost 2018-12-18 08:35:40 UTC
Created attachment 116987 [details]
The output of `heaptrack_print` for krusader process which consumed 1.9GB of memory

(In reply to Nikita Melnichenko from comment #19)
> 
> Can you try tools like heaptrack
> (http://milianw.de/blog/heaptrack-a-heap-memory-profiler-for-linux, PEAK
> MEMORY CONSUMERS) or massif and let us know? Thanks!

I'm attaching the output of `heaptrack_print` for krusader which consumed 1.9GB of memory.
The heaptrack .gz data file is 320MB in size and I can send it via email on request.
Comment 23 Bug Janitor Service 2019-01-02 03:44:17 UTC
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!
Comment 24 Piotr Dobrogost 2019-01-02 10:12:01 UTC
Requested info attached in comment 22.
Comment 25 Nikita Melnichenko 2019-05-24 06:27:57 UTC
From the report, the peak allocations happen in Qt5 and KF5 libs. I don't see any actual krusader code involved, just internal event handlers.

Most heap peak is coming from libKF5Solid, which is a hardware tracker. Wild guess: if you have a faulty hardware that keeps disconnecting-reconnecting, it frequently triggers those event in Solid, which connect Qt objects and doing other stuff keeping track every such event. When you close Krusader, all the memory from this "hardware log" is freed and we see no leaks.

It will be helpful if you get debug symbols for KF5 libs as well and rerun the tool, then it may give us a clue on what kind of event it is.
Comment 26 Bug Janitor Service 2019-06-08 04:33:07 UTC
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!
Comment 27 Bug Janitor Service 2019-06-23 04:33:09 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now 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

Thank you for helping us make KDE software even better for everyone!
Comment 28 PhobosK 2020-04-04 16:36:12 UTC
Well I have this bug also and its been more than 3 years now with all the KDE and Krusader versions that were at that time (my system is Gentoo and is always up to date with current KDE versions)
When Krusader works with local folders there is no mem consumption, but as soon as I open a tab with the sftp: or fish: kio, even if i close it the mem consumption goes up to a point Krusader becomes non responsive and mem is usually above 5 Gb just for an hour of  staying in the same sftp folder and doing nothing.
The same kio protocols do not have this effect on dolphin...
Config:
KDE Frameworks 5.68.0
Qt 5.14.1 (built against 5.14.1)
The xcb windowing system
Krusader version 2.7.2 Gentoo system
Kernel 5.5.2-gentoo-x86_64
Comment 29 Ivo Smelhaus 2020-06-25 09:42:24 UTC
I can confirm the same or similar behavior during last year, when I use krusader every day.
In my case Kubuntu 18.04 and 20.04 (Phenom II X4 + 16GB + 500G SSD ext4 + 2x 1T HDD zfs) and Krusader from packages and sources 2.7.2 and git without noticeable change. 
No changes correlated to work with or without archive and/or remote filesystem. Just leaving it with few tabs pointing to local directories overnight brings the same effect.
Dolphin never caused any problem in the same circumstances.
So from user point of view:
1. Start Krusader - work perfect and very fast - MEM 380/120M (RES/VIRT acc htop)
2. leave it without touch overnight
3. Reaction to every mouse movement in seconds and even writing to internal console has a lag - MEM 4600M/4300M 
4. Stop and start Krusader and get to state 1. :-)

If I can help you finding the cause, let me know.
Comment 30 David 2020-10-27 16:26:21 UTC
Same on Kubuntu 20.04.1, Krusader 2.7.2. It seems it worsened after I added new 2 TB SSD disk to my laptop. Krusader's UI extremely slows down after several minutes, even opening Help -> About Krusader takes 10 seconds.
I have still some 25 GB of free RAM, Krusader takes now 5 GB RAM, 4 threads, but even when I do nothing, Krusader generates 4-6% CPU load (more than all my three open browsers with hundred of tabs).
Comment 31 Nikita Melnichenko 2020-11-25 23:58:41 UTC
@Piotr, @PhobosK, @Ivo, @David - I feel your pain and would like to help, especially since I should have some time for Krusader till the end of year. However, I need your help as well. It seems like it's quite a rare issue. I tried to repro it in various ways and I could not. I need an additional information from you to produce some ideas on what is wrong.

Please read my discussion with @Piotr, especially comment #25. Could you invest some of your time to provide a heaptrack report while running on a system with debug symbols for KDE Frameworks and Qt. The problem is likely related to KF5 Solid lib (either leak there or maybe some abnormal API usage), but it's hard to understand what exactly is wrong and what is different in your systems compared to an average system.

If we localize the issue, I may be able implement some workarounds in the code for you to try.
Comment 32 David 2020-11-26 19:32:25 UTC
Blah, bugzilla doesn't want to allow me to send big files. But I can reproduce it whenever you ask, so you can contact me on my e-mail.

I tried to run krusader with heaptrack, but as I am not experienced with debugging Linux applications I probably need more detailed instructions (commands what to install, what to execute).

But basically this is suspicious for me:

158.57MB peak memory consumed over 972428 calls from
QAction::QAction(QObject*)
in /lib/x86_64-linux-gnu/libQt5Widgets.so.5
157.78MB consumed over 769860 calls from:
QAction::QAction(QString const&, QObject*)
in /lib/x86_64-linux-gnu/libQt5Widgets.so.5
QAction::QAction(QIcon const&, QString const&, QObject*)
in /lib/x86_64-linux-gnu/libQt5Widgets.so.5
0x7ffff7f4d203
in /lib/x86_64-linux-gnu/libKF5KIOFileWidgets.so.5
QMetaObject::activate(QObject*, int, int, void**)
in /lib/x86_64-linux-gnu/libQt5Core.so.5
QAbstractItemModel::dataChanged(QModelIndex const&, QModelIndex const&, QVector<> const&)
in /lib/x86_64-linux-gnu/libQt5Core.so.5
0x7ffff7f16bd8
in /lib/x86_64-linux-gnu/libKF5KIOFileWidgets.so.5
0x7ffff7f1d2ec
in /lib/x86_64-linux-gnu/libKF5KIOFileWidgets.so.5
QMetaObject::activate(QObject*, int, int, void**)
in /lib/x86_64-linux-gnu/libQt5Core.so.5
Comment 33 Nikita Melnichenko 2020-12-07 08:07:22 UTC
Thanks David. I've sent you an email.
Comment 34 Nikita Melnichenko 2021-01-23 07:05:42 UTC
After a few iterations with David, we were able to get a stack with debug symbols and it helped to localize the problem: it's been in an upstream component - either solid lib or KIOFileWidgets.

David upgraded the system from 20.04 to 20.10 and the issue is gone for him. KF5 version has changed from 5.68 to 5.74. If you experience an issue like this, try to upgrade KF5 libs to the latest or at least to >= 5.74. Let us know if you still have the problem.

Thanks David and Toni!
Comment 35 PhobosK 2021-01-23 08:27:51 UTC
Sorry but this still happens for me on KF5 5.78 and Plasma 5.20.5 and Apps 20.12.1

It is hard for me to debug because it needs some time Krusader to run (like some 4-6 ours of use) and use it.

What's interesting that when run as root this is not happening, but again in that profile KDE is not configured and no sftp etc bookmarks are used.
Comment 36 Nikita Melnichenko 2021-01-23 21:46:16 UTC
(In reply to PhobosK from comment #35)
> Sorry but this still happens for me on KF5 5.78 and Plasma 5.20.5 and Apps
> 20.12.1

I think yours is a different issue. You mentioned it happens with network fs only. It's not exactly "doing nothing" like in Piotr's or David's cases. ;) Nevertheless, I can still help if you provide debug tool output.


> It is hard for me to debug because it needs some time Krusader to run (like
> some 4-6 ours of use) and use it.

There is no need to debug from your side, just follow these simple steps:
1. emerge heaptrack (needs unmasking).
2. In console run "heaptrack krusader" and use it as normal for a while until you experience 1+ Gb of memory allocated. Unlike valgrind, perf loss is only about 10-15%.
3. Share the heaptrack.krusader.xxxx.gz file via some file sharing service like gdrive. It contains backtraces for all the allocations happened during the run, so we can track down what's the memory is used for.
Comment 37 Ivo Smelhaus 2021-09-03 16:45:57 UTC
Kubuntu 20.04 is a last LTS with no plan to change KF and this bug is almost a blocker for using of Krusader. Is there a chance, that this bug will resolve for this KUbuntu 20.04? If there is something, I can help, I'll do it. 
I use Krusader (compiled from git) everyday and suffer with this bug a lot, because of I have to restart Krusader few times a day and even between the restarts causes a big usage of swap. So not to solve it for this release means make the app, you dev, not usable for more than next one year.
Comment 38 David 2021-09-03 19:50:40 UTC
(In reply to Ivo Smelhaus from comment #37)
> So not to solve it for this release means make the app, you dev, not usable for more than next one year.

Since Nikita helped me to reproduce the issue and send him some data about it and then he also fixed something, so at least on my machine is the leak very rare (now it takes 512 MB of 64 GB available after 7 days of Krusader running, and I have enabled even image previews).

But it is not completely gone, as I wrote, from time to time it is like a nuke, Krusader suddenly "explodes". I have no idea why.

If you can reliably reproduce it (I cannot), perhaps you can help @Nikita with the diagnose.
Comment 39 PhobosK 2021-09-04 21:03:22 UTC
Created attachment 141297 [details]
heaptrack.krusader.jpg

I found something very strange about this memory hog....

It still happens on my system - right after krusader is started it has some 20-30 sec delay before its window is painted, the next 10 min it gets >200 Mb mem usage and for an hour it ups to 1.5 Gb.

I found that there is mem leaking connected to KDirWatch, started by KBookmarkManager.

The truth is I have around 50 bookmarks from diff protocols - sftp:/, file:/, smb:/ - and some of them were old with missing paths. So I decided to leave only those working - ~20 - but it didn't help.
I turned off the search in bookmarks too - but it didn't help either.

Krusader from my root profile with only 5 bookmarks with the file:/ protocol doesn't have this memory problem + it starts (paints) the window almost immediately after the start and memory usage stays at max 30 Mb for a long time....

I am sorry that I attach a screenshot only of heaptrack, but this is taken on the 15 min of usage of krusader and is sorted by "Leaked" memory.

The system is: 
Krusader 2.7.2
KDE Frameworks 5.85.0
KDE Apps 21.08.1
Qt 5.15.2
The xcb windowing system

I do not know if it is relevant (I think KDirWatch is also dependent on it) but because of baloo and idea I have set:
fs.inotify.max_user_watches = 524288

I hope this will help

Thanks
Comment 40 PhobosK 2021-10-28 17:51:25 UTC
Turns out the reason for all this is baloo. 
I have a lot of pics with tags etc that baloo is indexing.
The moment baloo is turned off and its database is cleared, krusader starts to work normally and barely consumes memory...

I dunno if there is a way so krusader doesn't use any baloo stuff ???