Summary: | Memory Leak / Memory Usage For Large Feeds | ||
---|---|---|---|
Product: | [Applications] akregator | Reporter: | barray <barray> |
Component: | general | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | REPORTED --- | ||
Severity: | crash | CC: | barray, montel |
Priority: | NOR | ||
Version: | 5.16.3 | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
RAM usage over 24 hours
Valgrind log after running akgregator for a few hours RAM usage over time for built-from-source version Replicated RAM usage issue in a debug build Valgrind log after running for quite a few hours on built source |
Description
barray
2021-08-03 22:40:26 UTC
I'm logging the RAM usage every 300 seconds using the SO answer here: https://unix.stackexchange.com/a/508799 The code is: ``` delay=300 pid="$1" top -b -d $delay -p $pid | awk -v OFS="," '$1=="top"{ time=$3 } $1+0>0 { print time,$1,$NF,$9,$10; fflush() }' ``` This gives RAM as a percentage of total memory, but should allow the observation of memory increase to be obvious. The purpose of doing this is to see whether it is linear (memory leak in small loop), periodic (when feeds are pulled) or sporadic (specific feed content is leaking memory). It also will show the extent of this problem. Created attachment 140527 [details]
RAM usage over 24 hours
The attached image shows increased RAM usage of Akregator over a 24+ hour window - something weird is definitely going on here. I'll try to attach valgrind later and see what is specifically growing.
Created attachment 140528 [details]
Valgrind log after running akgregator for a few hours
Thanks for valgrind report. I will look at it. Thanks I have built from source (v20.12.3) and am now making sure it still replicates. If so, I plan to get a better valgrind output - as well as confirm the issue in later versions. Created attachment 140567 [details] RAM usage over time for built-from-source version This is the built-from-source version - the issue doesn't appear to replicate (at least not to the same level). It also crashes when selecting the menu item: `Settings > Configure Akregator`, giving: ./bin/akregator: symbol lookup error: /usr/lib/x86_64-linux-gnu/qt5/plugins/akregator_config_userfeedback.so: undefined symbol: _ZN9Akregator19UserFeedBackManager4selfEv I suspect it could be some issue with the archiving [1]. I spoke with @pinaraf in #akregator on Libera IRC and they seemed to believe there are some large flaws in the archiving process in any case. [1] https://bbs.archlinux.org/viewtopic.php?id=226889 (In reply to barray from comment #6) > Created attachment 140567 [details] > RAM usage over time for built-from-source version > > This is the built-from-source version - the issue doesn't appear to > replicate (at least not to the same level). > > It also crashes when selecting the menu item: `Settings > Configure > Akregator`, giving: > > ./bin/akregator: symbol lookup error: > /usr/lib/x86_64-linux-gnu/qt5/plugins/akregator_config_userfeedback.so: > undefined symbol: _ZN9Akregator19UserFeedBackManager4selfEv > > I suspect it could be some issue with the archiving [1]. > > I spoke with @pinaraf in #akregator on Libera IRC and they seemed to believe > there are some large flaws in the archiving process in any case. > > [1] https://bbs.archlinux.org/viewtopic.php?id=226889 You rebuild akregator but it seems that it uses akregator_config_userfeedback.so from your system not you install directory. If you rebuild remove your akregator from your system first. (In reply to Laurent Montel from comment #7) > You rebuild akregator but it seems that it uses > akregator_config_userfeedback.so from your system not you install directory. > If you rebuild remove your akregator from your system first. I have done this and will try to replicate the issue again. I can now access the menus and metakit appears to be working. Created attachment 140591 [details]
Replicated RAM usage issue in a debug build
As you can see, I am now able to replicate the RAM usage issue in a debug build. The next step for me is to run this under valgrind and try to generate more useful output.
After that I want to run on the latest release tag and try to replicate the issue there.
Created attachment 140612 [details]
Valgrind log after running for quite a few hours on built source
It was horrifically slow, but I tried to use it as normal over a decent time window. Hopefully this valgrind log is more useful for debugging memory use.
My experience of reading valgrind output is quite limited, but I will take a look in a few days.
In the meantime, if you would like me to check anything else, please let me know.
|