Bug 1830885
| Summary: | Probable memory leak in mate-panel-1.24.0-4.fc32 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Davide Repetto <red> |
| Component: | mate-panel | Assignee: | Wolfgang Ulbrich <fedora> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 32 | CC: | fedora, stefano, tbzatek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | mate-panel-1.24.0-5.fc32 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-06-02 03:53:33 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Attachments: | |||
Created attachment 1684734 [details]
A view of the memory usage in system monitor
This is what system monitor has to say while mate-panel's using 4.7GB of ram.
Yes, i started building mate-panel again with in-process-applets for f32, to make it sure that the panel can be used in a wayland-compositor and X11. Mate-panel supports wayland now and out-of-process applets don't work here. But i am using this config since over 1 year for myself (f30) and i never noticed such a huge memory consumption like you said. Well, i will take a look at the process again and see how much memory is used in the evening before i shutdown my system. Now i stated with about ~ 60MiB. Which applets are you using? Only the applets from mate-panel package itself are build-in-process. Which panel setup are you using? Sadly, i didn't find the time to switch from f30 to f32 yet. F32 is installed as dual-boot, but usually i am using f30. PS: Please post screenshots in English. LANG=C mate-system-monitor Created attachment 1685158 [details] mate-panel memory usage in English (In reply to Wolfgang Ulbrich from comment #2) > Yes, i started building mate-panel again with in-process-applets for f32, to > make it sure that the panel can be used in a wayland-compositor and X11. > Mate-panel supports wayland now and out-of-process applets don't work here. > But i am using this config since over 1 year for myself (f30) and i never > noticed such a huge memory consumption like you said. > Well, i will take a look at the process again and see how much memory is > used in the evening before i shutdown my system. > Now i stated with about ~ 60MiB. Ok, so it's the same situation as the other time. It's good, because we have an easy workaround and because wayland is not active by default in the Fedora32 mate spin. This gives us time to work toward a more permanent solution. > Which applets are you using? applet-iid='NotificationAreaAppletFactory::NotificationArea' applet-iid='CPUFreqAppletFactory::CPUFreqApplet' applet-iid='CPUFreqAppletFactory::CPUFreqApplet' applet-iid='WnckletFactory::WorkspaceSwitcherApplet' applet-iid='WnckletFactory::WindowListApplet' applet-iid='GvcAppletFactory::GvcApplet' applet-iid='SensorsAppletFactory::SensorsApplet' applet-iid='MultiLoadAppletFactory::MultiLoadApplet' applet-iid='TrashAppletFactory::TrashApplet' applet-iid='WnckletFactory::WindowMenuApplet' applet-iid='ClockAppletFactory::ClockApplet' applet-iid='WnckletFactory::ShowDesktopApplet' > Only the applets from mate-panel package itself are build-in-process. > Which panel setup are you using? You can get the details from attachment 1684721 [details] in the first post. > Sadly, i didn't find the time to switch from f30 to f32 yet. > F32 is installed as dual-boot, but usually i am using f30. From what I gather right now, the NotificationArea applet is the most likely culprit. In fact, the leakage starts only when certain combination of notification icons come and go. The one icon that seems to trigger the cascade regularly and predictably is the eMule icon. (eMule runs under wine) When the leak is not triggered the panel idles at 130-150MB, with about 30MB of heap and 108MB of locale cache. If necessary I can supply a Virtual machine, accessible via Internet, where the problem is replicated. > PS: Please post screenshots in English. There you go. English screenshot :) Created attachment 1686190 [details]
Another screenshot showing high usage
This screenshot relates to the memory usage of the panel after more than 24 hours in which I accurately avoided any of the programs that can trigger the massive cascade of memory leaks.
Yet, as you can see there is still significant memory leaking, albeit much slower. At this rate though, multi gigabytes can still be reached in about a week of uninterrupted up time.
Hope it helps.
OMG, i never use wine because of unwanted .i686 files. And i don't share files with emule. Why not using amule, the linux donkey client? When i need windows software i fire up a win10 VM :) Any way, in my test the the panel usually closed with maximum 200 MB in the evening after 12-16 hours. I will built a panel version with out-process-applets for testing for you. Here we have a single panel, clock-applet, notification-area-applet and a wnck-applet (workspace-switcher, windows-list, show-desktop and menu) as processes. So in theory you should see the high memory consumption for the single notification-area-applet process. Or maybe it is only a problem when the panel is build with in-process-applets. I recall that we had always this problems with the notification-area-applet in the past. You can also try to disable the new windows-list-preview feature, maybe this has an influence too. There is a setting in windows-list preferences. Scratch build with out-of-process-applets. https://koji.fedoraproject.org/koji/taskinfo?taskID=44569416 Let me know your results, please. (In reply to Wolfgang Ulbrich from comment #5) > OMG, i never use wine because of unwanted .i686 files. And i don't share > files with emule. Well, I'm not _that_ strapped on disk space, so... > Why not using amule, the linux donkey client? Poor aMule, it's an unmaintained mess. It lacks most features and those few it has do not even work well. Really sad. :( > When i need windows software i fire up a win10 VM :) Me too, I love VMs. But for this purpose wine is a much better fit. > Any way, > in my test the the panel usually closed with maximum 200 MB in the evening > after 12-16 hours. Well, you're in FC31, aren't you? Maybe something's different there? In FC32 the situation is such that the leaks are significant even in a clean install. (As in Comment 5) > I will built a panel version with out-process-applets for testing for you. > Here we have a single panel, clock-applet, notification-area-applet and a > wnck-applet (workspace-switcher, windows-list, show-desktop and menu) as > processes. > So in theory you should see the high memory consumption for the single > notification-area-applet process. > Or maybe it is only a problem when the panel is build with > in-process-applets. > I recall that we had always this problems with the notification-area-applet > in the past. Yes. It seems that it is only a problem when the panel is built with in-process-applets. I kept pounding the scratch build with eMule & C. for the past few hours and I can see no leaks. I'll let you know if things change after 24/48 hours of up time. > You can also try to disable the new windows-list-preview feature, maybe this > has an influence too. > There is a setting in windows-list preferences. Actually I disabled the windows-list-preview because it doesn't work very well and frankly it's kind of a nuisance to me. (In reply to Davide Repetto from comment #7) > (In reply to Wolfgang Ulbrich from comment #5) > > Any way, > > in my test the the panel usually closed with maximum 200 MB in the evening > > after 12-16 hours. > > Well, you're in FC31, aren't you? Maybe something's different there? > > In FC32 the situation is such that the leaks are significant even in a > clean install. (As in Comment 5) > I switched from f30(mate-1.24) to f32 the last days and official f31 is updated to 1.24 since a few days. Mainly the out-of-process version was running the last days. but i will test the in-process version again. I was only surprised about your 2GB result from first post. My na-tray applets are usually - keepassXc - deadbeef audio player - dropbox - mate-monitor-tray-applet - transmission - nm-applet ... not more. Please watch those processes. mate-panel clock-applet notification-area-applet wnck-applet With in-process-applets all those single processes are one. So, you have to see the leak in one of those single processes....in theory. If not that might be a good hint for MATE upstream. Well, at least i can rebuild mate-panel to use out-of-process applets again, if it is better for you. The wayland support is very experimental, and i can build a wayland version at copr repo, if someone need it. > Mainly the out-of-process version was running the last days. but i will test > the in-process version again. > I was only surprised about your 2GB result from first post. :) Actually the first post was 4.6GB and I saw 14GB more than once. > My na-tray applets are usually > - keepassXc > - deadbeef audio player > - dropbox > - mate-monitor-tray-applet > - transmission > - nm-applet > > ... not more. Right now I'm purposely keeping a few more tray icons than usual, including those that proved to be nasty with the in-process version. It's about 24 hours and I'm still seeing normal memory usage. > Please watch those processes. > mate-panel > clock-applet > notification-area-applet > wnck-applet > > With in-process-applets all those single processes are one. > So, you have to see the leak in one of those single processes....in theory. > If not that might be a good hint for MATE upstream. Will do. In the next few days I'll report my findings. > Well, at least i can rebuild mate-panel to use out-of-process applets again, > if it is better for you. > The wayland support is very experimental, and i can build a wayland version > at copr repo, if someone need it. Of course that would be ok, but I'm more than happy to help find a proper solution. Created attachment 1691028 [details]
Here's the memory consumption of the "Out Of Process" mate-panel after 4 days.
After 4 days of purposefully heavy usage I can see no trace of memory leaks in the mate-panel built with Out Of Process Plugins.
FEDORA-2020-9b86f77580 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-9b86f77580 Guys, please leave karma at bodhi (In reply to Davide Repetto from comment #10) > Created attachment 1691028 [details] > Here's the memory consumption of the "Out Of Process" mate-panel after 4 > days. > > After 4 days of purposefully heavy usage I can see no trace of memory leaks > in the mate-panel built with Out Of Process Plugins. David, can you please check the process `wnck-applet` , which is windows-list, workspace-switcher and show-desktop when build out-of-process. FEDORA-2020-9b86f77580 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-9b86f77580` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-9b86f77580 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-9b86f77580 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. |
Created attachment 1684721 [details] dconf dump of /org/mate/panel/ Description of problem: ======================= A few hours ago I noticed mate-panel using more than 14GB. After a "pkill -QUIT mate-panel" it was back at 88MB, but it started climbing immediately. A couple of hours later it was already over 2GB. Version-Release number of selected component (if applicable): ============================================================= mate-panel-1.24.0-4.fc32.x86_64 Additional info: ================ Please find my mate-panel config in the attachments. I don't know if it may be related, but there was a similar situation in the past, when the panel was compiled with "in process plugins" and was leaking memory like there's no tomorrow. Please let me know if I can help in any way.