Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

mate-panel high memory usage if build with in-process #809

Closed
prarit opened this issue May 10, 2018 · 104 comments
Closed

mate-panel high memory usage if build with in-process #809

prarit opened this issue May 10, 2018 · 104 comments

Comments

@prarit
Copy link

prarit commented May 10, 2018

Expected behaviour

mate-panel does not consume 9G of memory

Actual behaviour

mate-panel has consumed 9G of memory. Eventually attempting to start applications from the mate-panel will fail with memory errors. Starting the application from a previously opened terminal does work.

Steps to reproduce the behaviour

Unknown. I am using the mate desktop on my day-to-day workstation. I am not doing anything unusual.

MATE general version

mate-about shows version 1.20.1

mate-desktop-1.20.1-3.fc27.x86_64

Package version

mate-panel-1.20.1-5.fc27.x86_64

Linux Distribution

F27

Link to downstream report of your Distribution
@prarit prarit changed the title mate-desktop high memory usage mate-panel high memory usage May 10, 2018
@prarit
Copy link
Author

prarit commented May 10, 2018

##Link to downstream report of your Distribution

https://bugzilla.redhat.com/show_bug.cgi?id=1576930

P.

@raveit65
Copy link
Member

Do you use windows-applets via wine in na-tray?
See https://bugzilla.redhat.com/show_bug.cgi?id=1575091

@prarit
Copy link
Author

prarit commented May 10, 2018 via email

@prarit
Copy link
Author

prarit commented May 10, 2018

Current mate-panel memory consumption is over 50%:
2203 prarit 20 0 14.706g 0.013t 26864 S 5.3 50.9 98:26.53 mate-panel

If I attempt to launch any application through the panel I get a "Failed to fork (cannot allocate memory)" error.

@prarit
Copy link
Author

prarit commented May 10, 2018

OOC (I couldn't find an answer searching online) is there a way to restart the mate-panel? I know of "--reset" but that kills all my settings.

@raveit65
Copy link
Member

'killall mate-panel', restart happens automatic via session management.

@raveit65
Copy link
Member

which is 'kill -9'

@lukefromdc
Copy link
Member

How long does that workstation normally run between reboots? How long on a new boot before you see 9GB of RAM consumed by the panel?

Right now, after 6 min run on a new boot(encrypted machine always shut down when not in use), I see 38MB in use. I've seen 60 or so in long, complex sessions but that's about it

@alexarnaud
Copy link
Member

alexarnaud commented May 11, 2018 via email

@raveit65
Copy link
Member

If I attempt to launch any application through the panel I get a "Failed to fork (cannot allocate memory)" error.

With a panel launcher, from menu or with alt+f2

@prarit
Copy link
Author

prarit commented May 11, 2018 via email

@prarit
Copy link
Author

prarit commented May 11, 2018 via email

@alexarnaud
Copy link
Member

alexarnaud commented May 11, 2018 via email

@lukefromdc
Copy link
Member

Since another report indicated the tray built in-process was a cause of this, I ran cppcheck-gui on the notification-area directory with all the messages turned on, and got these results which don't show anything that would be expected to be the cause of this:

na-resources.c,0,information,The configuration '_MSC_VER;_WIN64' was not checked because
its code equals another one.

na-resources.c,0,information,The configuration '__ELF__' was not checked because its code
equals another one.

main.c,0,information,The configuration 'GDK_WINDOWING_X11' was not checked because its
code equals another one.

na-box.c,0,information,The configuration 'GDK_WINDOWING_X11' was not checked because its
code equals another one.

libstatus-notifier-watcher/gf-sn-watcher-v0-gen.c,1754,style,The scope of the variable 'variant'
can be reduced.

libstatus-notifier-watcher/gf-sn-watcher-v0-gen.c,0,information,The configuration
'HAVE_CONFIG_H' was not checked because its code equals another one.

status-notifier/sn-dbus-menu-gen.c,3125,style,The scope of the variable 'variant' can be
reduced.

status-notifier/sn-dbus-menu-gen.c,0,information,The configuration 'HAVE_CONFIG_H' was not
checked because its code equals another one.

system-tray/na-tray-manager.c,54,style,struct member 'PendingMessage::id' is never used.

system-tray/na-tray-manager.c,54,style,struct member 'PendingMessage::len' is never used.

system-tray/na-tray-manager.c,55,style,struct member 'PendingMessage::remaining_len' is
never used.

system-tray/na-tray-manager.c,57,style,struct member 'PendingMessage::timeout' is never
used.

system-tray/na-tray-manager.c,58,style,struct member 'PendingMessage::str' is never used.

status-notifier/sn-watcher-v0-gen.c,1754,style,The scope of the variable 'variant' can be
reduced.

status-notifier/sn-watcher-v0-gen.c,0,information,The configuration 'HAVE_CONFIG_H' was not
checked because its code equals another one.

status-notifier/sn-item-v0-gen.c,2809,style,Variable 'value' is reassigned a value before the old
one has been used.

status-notifier/sn-item-v0-gen.c,2837,style,Variable 'value' is reassigned a value before the old
one has been used.

status-notifier/sn-item-v0-gen.c,2865,style,Variable 'value' is reassigned a value before the old
one has been used.

status-notifier/sn-item-v0-gen.c,2893,style,Variable 'value' is reassigned a value before the old
one has been used.

status-notifier/sn-item-v0-gen.c,3620,style,The scope of the variable 'variant' can be reduced.

status-notifier/sn-item-v0-gen.c,0,information,The configuration 'HAVE_CONFIG_H' was not
checked because its code equals another one.

status-notifier/sn-host-v0-gen.c,0,information,The configuration 'HAVE_CONFIG_H' was not
checked because its code equals another one.

@prarit
Copy link
Author

prarit commented May 14, 2018

The build in https://bugzilla.redhat.com/show_bug.cgi?id=1576930#c2 works AFAICT. mate-panel has very low memory usage:

2196 prarit 20 0 749068 73236 22052 S 0.0 0.3 0:14.88 mate-panel

@raveit65
Copy link
Member

Ok, sounds like i have to switch mate-panel build back to out-of process in fedora.
@prarit
Can you do a last test for us again?
We like to know which applet causes the high load?
Because building panel with applet in-process (fedora repo version)= all applets from mate-panel package use the same process.
Building panel with applets out-of-process (test build and old builds)= every applet use a single process.

That means the high load of the panel process is caused by an applet.
So can you test panel build from repos without notification-area-tray?
We need to know if this applet is the culprit.
Or not with all na-tray applets which you are using normal?
To find out which tray-applet causes the issue.

I know this isn't very comfortable...........thank you.

@lukefromdc
Copy link
Member

Why is this different in Fedora than in Debian is the other question. Rather hard to work on this when I can't get it to happen here.

@raveit65
Copy link
Member

raveit65 commented May 15, 2018 •
edited
Loading

Why is this different in Fedora than in Debian is the other question. Rather hard to work on this when I can't get it to happen here.

I think you don't use his application-tray-applet which trigger the issue, maybe?

@raveit65 raveit65 changed the title mate-panel high memory usage mate-panel high memory usage if build with in-process May 15, 2018
@prarit
Copy link
Author

prarit commented May 15, 2018

That means the high load of the panel process is caused by an applet.
So can you test panel build from repos without notification-area-tray?
We need to know if this applet is the culprit.
Or not with all na-tray applets which you are using normal?
To find out which tray-applet causes the issue.

Sure ... If you can give me detailed instructions on what you'd like me to do :)

@raveit65
Copy link
Member

I thought that was instruction enough :)
All with culprit version from fedora repos.

First test without using the tray-applet in panel.

  1. right click on the grid area left from na-tray applet.
    Here choose un-lock the applet.
  2. right-click again and choose remove the applet.

Second test with the na-tray-applet.
I don't know which application you use which are loading applets inside the na-tray-applet :)
Most applications with tray-applets have an option to disable the tray applet.

@prarit
Copy link
Author

prarit commented May 16, 2018

I see, you want me to trim down my applets :). I'm going to figure out a way to do this. The problem is that the vnc session I run in is my main desktop :( so I'm adverse to doing any testing there.

BUT :) I do have room to create more guests on my host. I'm going to see if I can create a new F27 test environment and see if I can reproduce. Again, keep in mind that the test takes ~4 days before reproducing so this is going to take some time to figure out.

@vkareh
Copy link
Member

vkareh commented May 20, 2018

@raveit65 - is this actually solved by building out of process? Can we change the default to be the clock and window list in process, everything else out of process? I've been working on this issue for quite a while and those are the only two applets that flicker. Also, I have a hack for the window-list one, so really it would be just the clock...

@vkareh
Copy link
Member

vkareh commented May 20, 2018

@lukefromdc - I've seen several reports of this on Ubuntu, so it is an issue there as well.
@raveit65 - Ubuntu uses the na-tray applet as well, but most of the icons are in the indicator applet instead (default layout has both applets actually)

@raveit65
Copy link
Member

@vkareh
Yes, the issue doesn't exists if the panel i build out of process and i agree with your suggestion.
I'd love to see several in/out-of-process build options for building the applets independent.
Building the na-tray appet in-process is needed in future for switching to wayland, than such issues needs to be fixed.
But than GtkStatusIcon is also dropped by gtk+4 ;)
So, at the moment this isn't really relevant.
But maybe we're lucky and we get more infos what exactly caused the issue from reporter, in result someone can reproduce it for fixing.

I've seen several reports of this on Ubuntu, so it is an issue there as well.

Is there one report with very specific tray applet which causes the issue?
I know that it can happen with wine applets, but this is one thing which i don't want to install on my box ;)

@vkareh
Copy link
Member

vkareh commented May 20, 2018

https://ubuntu-mate.community/t/mate-indicator-applet-using-5gb-ram/16844

Huh... That's for the indicator applet... 😕

@raveit65
Copy link
Member

I just switched back fedora builds to out of process.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-f11f17bf17
https://bodhi.fedoraproject.org/updates/FEDORA-2018-7cbfe6ab39
I suggest to leave the report open for finding the real culprit for this issue.

@lfir
Copy link

lfir commented May 24, 2018

Hello. I'm also having this issue on Fedora 27 (mate-panel-1.20.1-5.fc27.x86_64). I tried removing the notification area and then it didn't occur any more. The only applets I've running are the ones for the printer (/usr/share/system-config-printer/applet.py), network (NetworkManager Applet nm-applet) and volume (mate-volume-control-applet). I killed all of them but the memory consumption of mate-panel remains the same.
Regards.

@vkareh
Copy link
Member

vkareh commented May 24, 2018 •
edited
Loading

@Asta1986 - this is quite useful, actually. So you're saying that even with no icons showing in the notification area you still had high memory consumption? That must mean that the issue is with the applet itself, rather than with a specific icon that shows there...

@mrj
Copy link

mrj commented Nov 27, 2018

Thanks. I'm now trying 200px, which has moved the seconds away from the edge of the screen.

@jimlewis294
Copy link

I too have this issue on 2 recently updated Fedora 28 systems. I have both the clock with seconds AND a Java app which shows the disk space and this updates every 2 seconds. I have turned off the seconds on the clock and it does seem to have helped, at least a little.
Please excuse my ignorance but I am not much of a GUI person (command line nerd). I do not have a
~/.config/gtk-3.0/gtk.css file and so do not know where to put the change. I do have a
/usr/share/themes/TraditionalOk/gtk-3.0/gtk.css file, can I put the change there? And what do I have to do to get it to "see" the change?

Also, a big Thanks! for helping to track down this issue. I am seeing numerous problems with both F28 and F29 that previous versions did not have.

@mrj
Copy link

mrj commented Nov 27, 2018

jimlewis294, just create the ~/.config/gtk-3.0/gtk.css file, then log out and back in again. Killing the mate-panel process may have the same effect.

@lukefromdc
Copy link
Member

~/.config/gtk-3.0/gtk.css does not exist by default, you can simply create a new file in that directory and name it gtk.css it is used to store user overrides to all GTK themes

@raveit65
Copy link
Member

I do not have a
~/.config/gtk-3.0/gtk.css file and so do not know where to put the change.

Simply create an empty gtk.css at this place and add the lines to the file.

I do have a
/usr/share/themes/TraditionalOk/gtk-3.0/gtk.css file, can I put the change there?

If you like to apply a system wide change, add the lines at the end of mate-application.css
The order of reading is

  1. /usr/share/themes/TraditionalOk/gtk-3.0/gtk-widgets.css
  2. /usr/share/themes/TraditionalOk/gtk-3.0/mate-application.css
  3. ~/.config/gtk-3.0/gtk.css (This overrides all)

@jimlewis294
Copy link

Wow guys thanks for the quick response. I will create a new ~/.config/gtk-3.0/gtk.css file and put the change there.

@mrj
Copy link

mrj commented Dec 3, 2018

1.337GB after 6 days, even with a clock width that creates a blank space to the right of the seconds.

Trying now without the seconds.

@raveit65
Copy link
Member

raveit65 commented Dec 3, 2018

Do we really need the seconds in clock-applet?
I mean we have a timer-applet if someone needs the exact time for starting an application or what ever.

@lukefromdc
Copy link
Member

I have found if can be handy to use seconds for some jobs, but if this is setting a memory leak trap for users who leave it on and rarely reboot I could see removing it. Remember though that the same problems comes up if the netspeed applet is in the panel. That applet also tends to jump other applets and probably should get a minimum size for that reason.

@stefanct
Copy link

stefanct commented Dec 2, 2019

BTW, how would you customize the width of the netspeed applet? AFAICT is does not have a widget-name set so that it could be referred to by its name (no gtk_widget_set_name call).

@lukefromdc lukefromdc mentioned this issue Dec 7, 2019
Closed
@bozonius
Copy link

Not meaning to necro-post, but I think this is very relevant. I am using MATE 1.20.4 on Devuan Beowulf (Debian 10 minus systemd) and I am finding that with the seconds enabled on the panel clock, it is eating about 132 bytes per minute. I have this problem on 2 MATE desktop systems here.

I understand the desire to eliminate the feature altogether, but I actually like knowing that sluggishness or apparent freeze-up is due to some program rather than the entire system freezing up. There are other, maybe better ways to determine this, but this is very quick; don't have to wait up to a minute to find out. Just my 2c.

I just thought an update was appropriate. This defect continues in MATE 1.20.4.

@raveit65
Copy link
Member

raveit65 commented Dec 19, 2020 •
edited
Loading

Mate-1.20 reached EOL since 2 years.
Actual Mate version is 1.24.1 for more than half a year.
You should update your distro or better use a distro with modern package data base.

@bozonius
Copy link

I'm running Devuan Beowulf (Debian Buster). I think Debian 10.7 was just released. Is that not modern enough? Which distros/releases would you recommend?

@raveit65
Copy link
Member

No idea about MATE versions in debian.
But fedora-32/33/rawhide use mate-panel-1.24.1 which include a lot of memleak fixes. see https://github.com/mate-desktop/mate-panel/commits/1.24
Maybe ubuntu-20-10 use mate-panel-1.24.1 too?

@raveit65
Copy link
Member

If mate-panel-1.24.1 isn't build by debian you should file out a report there.

@stefanct
Copy link

It does and 20.04 (LTS) comes with 1.24.0
https://packages.ubuntu.com/search?keywords=mate-panel&searchon=names&suite=all&section=all

Debian stable is using 1.20.5 but the next release (next summer) will have >=1.24.1. Unfortunately it is not possible to install the testing version on stable (different libc dependencies): https://packages.debian.org/search?keywords=mate-panel&searchon=names&suite=all&section=all
One could file a report to ask for a backport though: https://lists.debian.org/debian-backports/

@prarit
Copy link
Author

prarit commented Dec 20, 2020

FWIW, I haven't experienced this bug in a long time. I'm currently running

[prarit@prarit ~]$ rpm -q mate-panel
mate-panel-1.24.1-1.fc33.x86_64

without any problems.

@raveit65 do you know if the build was ever "unmodified" to build with in-process? I've long since lost track :(

Depending on the answer to that question this issue can be closed IMO.

@raveit65
Copy link
Member

@prarit
With actual build in fedora the applets are build out-of-process, like it was before.
Can you give me a favor?
Do you like to test a in-process build of mate-panel-1.24.1-1.fc33.x86_64?
I am using for myself an in-process build of master branch and i don't see much memory consumption, after the bunch of mem-leak-fixes.
But i shutting down my system every evening.

@prarit
Copy link
Author

prarit commented Dec 20, 2020

Sure, np!

[prarit@prarit ~]$ rpm -q mate-panel
mate-panel-1.24.1-1.fc33.x86_64
[prarit@prarit ~]$

I'll try to remember to check back in a week to let you know how it goes.

@raveit65
Copy link
Member

@prarit
Thanks.
I did a test build with applets build in-process at koji build-server. (mate-panel-1.24.1-2.fc33)
I bumped version in result it is easy to install after download.
https://koji.fedoraproject.org/koji/taskinfo?taskID=58286367

@raveit65
Copy link
Member

@prarit
Did you test the RPM, should i push this to fedora?

@prarit
Copy link
Author

prarit commented Jan 28, 2021

Sorry, I completely forgot I was running this. Here's the problem: The fedora machine that I'm running this on is in my office and is only getting very occasional use due to COVID-19 restrictions. When I saw this problem I was using the box every day.

Can you possibly do a rebuild? I'll grab the RPM and install it on my day-to-day box that I'm currently using which is also F33.

@raveit65
Copy link
Member

@prarit
New build for f33 https://koji.fedoraproject.org/koji/taskinfo?taskID=60774915

@prarit
Copy link
Author

prarit commented Jan 29, 2021

@raveit65 , I've installed this on my local system. In case I forget (and I'm 100% sure I will unless something goes wrong ;)) ping me in a week and I'll let you know how it is going.

@raveit65
Copy link
Member

raveit65 commented Apr 5, 2021

@prarit
Any news?

@prarit
Copy link
Author

prarit commented Apr 5, 2021

Haha :) I just read my previous comment.

It's working fine as far as I can tell. I have seen no problems with this version.

@raveit65
Copy link
Member

raveit65 commented Apr 5, 2021

:)
Ok, than will switch mate-panel to build applets in-process for f34.
Closing.

@raveit65 raveit65 closed this as completed Apr 5, 2021
@raveit65
Copy link
Member

raveit65 commented Apr 5, 2021

@prarit
Do you like to give karma?
https://bodhi.fedoraproject.org/updates/FEDORA-2021-a5a80a509f

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests