memory usage - Githubissues

brizou commented 11 years ago

I have mate 1.6 on my archlinux install. mate-settings-daemon is using a lot of ram after a while, I just rebooted after three days, mate-daemon-settings was using 4.7Go of ram. I assume it's a memory leak but have now idea where the problem is

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/3035054-memory-usage?utm_campaign=plugin&utm_content=tracker%2F867277&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F867277&utm_medium=issues&utm_source=github).

sbalneav commented 11 years ago

Has this problem re-ocurred for you?

brizou commented 11 years ago

yes all the time, after a day or two, mate-settings-daemon is using a lot of ram and I have to reboot

sbalneav commented 11 years ago

Can you provide a little more information? I haven't got a lot to go on here. What apps are you running? Can you play around and see if running a specific app does it? Are you running a background slideshow? Any messages in ~/.xsession-errors?

Sorry, but I'm just not seeing that behaviour here.

brizou commented 11 years ago

Just saw your reply, I just rebooted. I will keep you posted if this happens again in the next couple of days. I think there wil be a mate update though

brizou commented 11 years ago

Here's what I have. after an hour this time (I had a lot of stuff opened in iceweasel, so itś normal if it takes a lot of ram) http://brizou.fr/dropcenter/php/action.php?action=openFile&file=../uploads/Capture-5.png

my daemon.log https://brizou.fr/zerobin/?d7a7f5a9c0dfa068#9i6F2EDEtyaB3l1c+qO9EGkv/cr4ws/GTBdHR4/OZYw=

gvfs seem to cause some problems but I can't remove it, a lot of softwares are using it

xsession-errors is empty

brizou commented 11 years ago

Now I have tis line, a lot, in everything.log May 16 15:47:14 clement-desktop slim[577]: (mate-settings-daemon:616): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed

sbalneav commented 11 years ago

Are you running on fedora?

brizou commented 11 years ago

no archlinux

MarkMT commented 11 years ago

I'm seeing a similar problem... it seems that whenever I adjust monitor resolution settings memory increases significantly. Since I do this frequently as I change from laptop internal monitor to external monitor a couple of times a day, memory usage by mate-settings-daemon escalates rapidly. By the time I get to around 4GB the machine becomes unusable and I have to reboot.

MarkMT commented 11 years ago

BTW, mate-settings-daemon version 1.4.0-2+precise and Mint 14

tkyjovsk commented 11 years ago

Hi, I have the same problem on Ubuntu 13.04 with mate-settings-daemon 1.6.0-2+raring. Whenever I open a popup menu of mate-display-properties tray icon, memory usage of the settings daemon jumps up to several GB.

szesch commented 11 years ago

Is it just opening the menu that causes the increase in memory usage, or does it occur after you have preformed some action in the menu?

MarkMT commented 11 years ago

Just opening the display settings dialog is causing the problem in my case. About 100MB each time.

MarkMT commented 11 years ago

BTW one other observation that may or may not be relevant... if I kill mate-settings-daemon, the desktop, app icons etc revert to a different low-res (or at least clunky) version. If I restart the process, the regular appearance of the desktop is mostly restored, but with one exception - Caja, which remains in the low-res state.

Yasen6275 commented 11 years ago

I have similar problem after hibernation. My system is Debian/testing. Usual programs running on my pc are icedove, iceweasel, chromium, skype(last non microsoft version). mate-settings-daemon cant be killed with sig 15 only with sig 9.

I'm note sure if the problem is in mate-settings-daemon or somewhere else because more rearly after hibernation i have problem with panel or a window opening and closing very fast with caption "caja x desctop" or something like that

flexiondotorg commented 10 years ago

Similar report in the MATE forum for Arch.

http://forums.mate-desktop.org/viewtopic.php?f=4&t=1824

DeveloperMCD commented 10 years ago

I got this problem today on Linux Mint 16, and I'm using the latest version of MATE.

balwierz commented 10 years ago

I confirm what MarkMT says: launching or even right clicking on display settings (as applet on mate-panel) causes a large jump of memory usage which is not freed when quitting the applet.

Arch Linux mate-settings-daemon-pulseaudio 1.6.2 Will try with dev version 1.7

balwierz commented 10 years ago

Actually it is not launching of "Monitor Preferences" that causes the issue. It is right clicking on the notification area applet of it. In my case 4.7GB get allocated !!

monsta commented 10 years ago

Another evidence of memory leak, this time in LMDE: http://forums.linuxmint.com/viewtopic.php?f=198&t=159793

nahall commented 10 years ago

I encountered this memory leak yesterday after upgrading my desktop to LDME UP8 (MATE 1.6.1-1). In my case, mate-settings-daemon was also using 100% CPU (one full core) in addition to gigabytes of RAM. Killing it made it respawn, but the respawned process started using 100% CPU and growing memory rapidly.

I noticed that the file .xsession-errors in my home directory was being filled with tons of lines of:

(mate-settings-daemon:4602): dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied.  dconf will not work properly.

every second (by the time I noticed, my .xsession-errors was over 500MB). I looked at the file /run/user/1000/dconf/user and it was set to have root permissions. I deleted the file, killed mate-settings-daemon, and now, when it respawned, it recreated that file as my user name, and now it doesn't seem to be using much CPU or memory. Not sure why the permissions got set wrong. I'm guessing it has something to do with sudo.

leo-unglaub commented 10 years ago

I have the same problem on Debian sience a few days. mate-settings-daemon is using up to 800 MB of ram.

mate-settings-daemon-memory-usage

Greetings Leo

stefano-k commented 10 years ago

@LeoUnglaub something more to debug the problem? are you changing wallpaper often? do you have something interesting in .xsession-errors? are you using systemd? thanks

leo-unglaub commented 10 years ago

Hey, i am still at trying to reproduce it. Sadly the memory map is not very helpful, because all large memory users are [anon]. The only large element there is icon-theme.cache.

http://paste.debian.net/plain/85032

Greetings Leo

3dbloke commented 10 years ago

The same problem occurs with my LMDE 201403 (FINAL) Mate installation.

I've noticed it when using the Sound Preferences and VLC 2.1.1, with a Logitech 9000 USB webcam attached (trying to record video), while running System Monitor 1.6.1.

The same memory leak also happened using the Gnome-Sound-Recorder 3.4.0, again with Sound Preferences open and System Monitor.

In both cases, mate-system-daemon took around 90-100 percent of the CPU on my 32-bit dual core Intel T2500 2GHz system, with 3.2GB addressable memory.

As others have said,if the daemon is killed it restarts with the same bad behaviour.

I've been unable to reproduce the problem. I'll post here again if I can reliably do so.

--Thomas

catalin-hritcu commented 10 years ago

Same problem here, also with LMDE 201403. I think the fact that '/run/user/1000/dconf/user' has the wrong (root) permissions is crucial for this bug, and probably mate-settings-daemon is not the main culprit here, but whichever sudo-ed process broke those permissions. Looking at my 340MB .xsession-errors is seems that a lot of other processes (nm-applet, emacs, mate-power-manager, etc) have trouble once the permissions are corrupted. Some of them react more graciously than others, and mate-settings-daemon reacts particularly ungracefuly by eating up 1 CPU, 6GB of RAM and 340MB of .xsessions. As far as I can tell, the main workaround at the moment is deleting the offending file and killing mate-settings-daemon. On my machine it took around half an hour until it started eating memory again ... but not yet 1 CPU.

catalin-hritcu commented 10 years ago

I think I've found the culprit for the wrong permissions: The Mint Software manager.

hritcu@detained ~ $ ls -l /run/user/1000/dconf/user
ls: cannot access /run/user/1000/dconf/user: No such file or directory
[2]hritcu@detained ~ $ gksu mintinstall
glibtop: Non-standard uts for running kernel:
release 3.11-2-amd64=3.11.0 gives version code 199424

No bp log location saved, using default.
[000:000] Cpu: 6.60.3, x8, 2401Mhz, 15763MB
[000:000] Computer model: Not available
[000:000] Browser XEmbed support present: 1
[000:000] Browser toolkit is Gtk2.
[000:000] Using Gtk2 toolkit
No bp log location saved, using default.
[000:000] Cpu: 6.60.3, x8, 2401Mhz, 15763MB
[000:000] Computer model: Not available
[000:002] Warning(optionsfile.cc:47): Load: Could not open file, err=2
[000:002] No bp log location saved, using default.
[000:002] Cpu: 6.60.3, x8, 2401Mhz, 15763MB
[000:002] Computer model: Not available
[000:002] Browser XEmbed support present: 1
[000:002] Browser toolkit is Gtk2.
[000:003] Using Gtk2 toolkit
[000:002] Warning(optionsfile.cc:47): Load: Could not open file, err=2
[000:002] No bp log location saved, using default.
[000:002] Cpu: 6.60.3, x8, 2401Mhz, 15763MB
[000:002] Computer model: Not available
add_categories took 0.522 ms
build_matched_packages took 0.121 ms
java version "1.7.0_21"
OpenJDK Runtime Environment (IcedTea 2.3.9) (7u21-2.3.9-5)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
add_packages took 2175.822 ms
add_reviews took 308.270 ms
__init__ took 2913.610 ms
show_category took 3.648 ms
Killed
hritcu@detained ~ $ ls -l /run/user/1000/dconf/user
-rw------- 1 root root 2 Mar  8 17:39 /run/user/1000/dconf/user

catalin-hritcu commented 10 years ago

Returning to mate-settings-daemon, it seems that about any error (not just the permission problem with /run/user/1000/dconf/user) causes it to leak memory and fill .xsession-errors with zillions of repeated error messages. Here is another one:

    (mate-settings-daemon:4635): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

I'm getting 1.7MB of these messages in the .xsession-errors and the mate-settings-daemon takes 2.6GB RAM at the moment. No 100% CPU though.

mate-settings-demon

3dbloke commented 10 years ago

Following up my earlier comment, the problem occurred again today after I had been listening to some OGG podcasts using VLC (v2.1.1). As before, CPU is running high with mate-settings-daemon on 80-90 percent, and memory use increasing by around 2MB every few seconds. It was the unexpected whirring of my laptop's cooling fan that drew my attention to the problem. I had not touched any of the Mate settings recently. Other apps running: Firefox, Scrivener, Terminal, Deluge, CryptKeeper, Shutter. (no webcam attached this time)

inxi -F System: Host: whatever Kernel: 3.11-2-686-pae i686 (32 bit) Desktop: MATE 1.6.1 Distro: LinuxMint 1 debian Machine: System: Dell product: MM061 Mobo: Dell model: 0XD720 Bios: Dell version: A17 date: 06/13/2007 CPU: Dual core Intel CPU T2500 (-MCP-) cache: 2048 KB flags: (nx pae sse sse2 sse3 vmx) Clock Speeds: 1: 2000.00 MHz 2: 2000.00 MHz Graphics: Card: Advanced Micro Devices [AMD/ATI] RV515/M54 [Mobility Radeon X1400] X.Org: 1.14.3 drivers: ati,radeon (unloaded: fbdev,vesa) Resolution: 1680x1050@60.1hz GLX Renderer: Gallium 0.4 on ATI RV515 GLX Version: 2.1 Mesa 9.2.2 Audio: Card: Intel NM10/ICH7 Family High Definition Audio Controller driver: snd_hda_intel Sound: Advanced Linux Sound Architecture ver: k3.11-2-686-pae Network: Card-1: Broadcom BCM4401-B0 100Base-TX driver: b44 IF: eth0 state: down mac: 00:15:c5:aa:ca:0f Card-2: Intel PRO/Wireless 3945ABG [Golan] Network Connection driver: iwl3945 IF: wlan0 state: up mac: 00:13:02:c9:b6:d0 Drives: HDD Total Size: 500.1GB (27.4% used) 1: id: /dev/sda model: ST9500420AS size: 500.1GB Partition: ID: / size: 29G used: 4.6G (17%) fs: ext4 ID: /home size: 426G used: 124G (31%) fs: ext4 ID: swap-1 size: 4.19GB used: 0.00GB (0%) fs: swap Sensors: System Temperatures: cpu: 54.5C mobo: N/A Fan Speeds (in rpm): cpu: N/A Info: Processes: 161 Uptime: 2 days Memory: 1617.4/3293.3MB Client: Shell (bash) inxi: 1.9.14

monsta commented 10 years ago

@3dbloke: in LMDE this bug can be worked around like this: http://forums.linuxmint.com/viewtopic.php?f=198&t=159793&start=20#p835353

linas commented 9 years ago

Still happening with the latest Mint17 qiana release.(based on ubuntu 14.04)

I'm leaking 1-2 gigbytes/minute! so it blows out system ram in about 5 minutes or less. Everything was fine until I started a google hangout session.

~/.xsession-errors is filled with zillions of these: (mate-panel:2767): dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied. dconf will not work properly.

cat .xsession-errors |grep "dconf-CRIT" |wc 15282244 229233660 2269203289

OK, so 15 million of these errors ... bad ...

linas commented 9 years ago

OK, so I quickly found the suggested work-around: remove systemd and libpam-systemd as per http://forums.linuxmint.com/viewtopic.php?f=198&t=159793&start=20#p835353

However, it unclear if this work-around will render a mint-17 system unbootable ...

At any rate, mate-settings-daemon should not leak memory just because of some bad file permissions...

monsta commented 9 years ago

However, it unclear if this work-around will render a mint-17 system unbootable

It shouldn't as Mint/Ubuntu uses upstart as its init system (and systemd-sysv isn't installed).

linas commented 9 years ago

Hmm .. in my case, systemd was not actually installed. Removing libpam-systemd will cause a few dozen packages to get removed, including mate-panel and mate-applets, so that seems like a non-starter.

monsta commented 9 years ago

Ok, so no easy way out. Anyway, you can try to catch the moment /run/user/1000/dconf/user gets its ownership changed to root:root (that's the cause of mate-settings-daemon losing its mind).

For example, in Debian Testing I can always reproduce the ownership change by running pluma via gksu (see this bug report). Try to catch it. Run various apps via gksu, check that file's ownership by running ls -l /run/user/1000/dconf/user, then (if needed) change it back by running sudo chown you:you /run/user/1000/dconf/user, and so on.

linas commented 9 years ago

OK, so I can reproduce this simply by running pluma as root. Gory details of strace/ltrace are in the debian bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766464 and that it is happening very very early in gtk initialization.

A quick google reveals this: https://bugzilla.redhat.com/show_bug.cgi?id=753882 which reveals that: 1) the bug is more than 3 years old 2) it has bitten hundreds if not thousands of users 3) the culprit is pam_systemd which is "working as designed" 4) pam_systemd is looking at the environment variable XDG_RUNTIME_DIR which is set to /run/usr/1000 for most folks. The resulting file is clobbered. Try it: export XDG_RUNTIME_DIR=/run/user/bogus and then run any MATE/gtk/gnome program as root, and you will discover the file /run/user/bogus/dconf/user has been created and is owned by root.

So: 1) mate-settings-daemon still has to be fixed to not leak 16GBytes of RAM in 3-4 minutes 2) Someone needs to track down the XDG_RUNTIME_DIR thing, and fix it.

linas commented 9 years ago

Doh. Wrote too soon. Regarding point 2) Lennart Poettering himself weighs in and states: its not a bug, its a feature: See: https://bugzilla.redhat.com/show_bug.cgi?id=753882#c29 and commeent 31, with a cogent rebuttal in comment 34. A plausible fix in comment 35 Poettering is in denial in comment 42 while comment 43 shows the killer nature of the bug. Then there's comment 56 ... my eyes glaze over after a while. I finally understand why Poettering gets death threats, and why systemd is so widely and strongly hated. I'm not even using systemd, and I got stabbed in the back by it. Makes me angry.

Anyway: mate-settings-daemon still has to be fixed to not leak 16GBytes of RAM in 3-4 minutes

gustopn commented 9 years ago

Yes monitor notifications is where I tracked down the problem also. I have opened a separate issue back then, it seems to be caused by the same problem.

linas commented 9 years ago

After 6 months of no problems at all, it suddenly came back fast and furious, just now. No clue what triggered it, this time. FWIW I am using the latest and greatest Mint Rebecca. To recap:

The symptoms are: 1) ~/.xsession-errors is huge -- 1.6GB 2) it is filled with this error message: dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied. dconf will not work properly. 3) /run/user/1000/dconf/usr was owned by root with perms 600

The work-around is:

a) kill -9 mate-setting-daemon b) sudo chown myself:myself /run/user/1000/dconf/user or sudo rm /run/user/1000/dconf/user c) optionally remove .xsession-errors d) kill -9 mate-setting-daemon again, to restore sanity after above.

monsta commented 9 years ago

@clefebvre: looks like your latest systemd patch is needed in Mint 17.x too...

linas commented 9 years ago

Happened again, just now.

CoolAller commented 8 years ago

It is impossible to use DE MATE. All the same error described above (using 100% CPU and memory leak.) strace -f $(pidof mate-settings-daemon | sed 's/([0-9]*)/-p \1/g'):

6240 recvmsg(3, 0x7ffda79f9640, 0) = -1 EAGAIN (Resource temporarily unavailable) 6240 recvmsg(3, 0x7ffda79f9640, 0) = -1 EAGAIN (Resource temporarily unavailable) 6240 munmap(0x7f87d53b6000, 21236) = 0 6240 access("/run", F_OK) = 0 6240 stat("/run", {st_mode=S_IFDIR|0755, st_size=860, ...}) = 0 6240 access("/run/user", F_OK) = 0 6240 stat("/run/user", {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0 6240 access("/run/user/1000", F_OK) = 0 6240 stat("/run/user/1000", {st_mode=S_IFDIR|0700, st_size=140, ...}) = 0 6240 access("/run/user/1000/dconf", F_OK) = 0 6240 stat("/run/user/1000/dconf", {st_mode=S_IFDIR|0700, st_size=60, ...}) = 0

6240 open("/run/user/1000/dconf/user", O_RDWR|O_CREAT, 0600) = -1 EACCES (Permission denied)

6240 write(2, "\n(mate-settings-daemon:6240): dc"..., 150) = 150 6240 close(-1) = -1 EBADF (Bad file descriptor) 6240 open("/home/coolaller/.config/dconf/user", O_RDONLY) = 16 6240 fstat(16, {st_mode=S_IFREG|0644, st_size=21236, ...}) = 0 6240 mmap(NULL, 21236, PROT_READ, MAP_PRIVATE, 16, 0) = 0x7f87d53b6000 6240 close(16) = 0 6240 poll([{fd=3, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=3, revents=POLLOUT}]) 6240 writev(3, [{"\203\2\1\0", 4}, {NULL, 0}, {"", 0}], 3) = 4 6240 poll([{fd=3, events=POLLIN}], 1, 4294967295) = 1 ([{fd=3, revents=POLLIN}]) 6240 recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"\1\2\353+\200\0\0\0\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 544

This continues from 2013, is it really impossible to fix? Do something with this error, please! DE MATE 1.8.1 Debian 8 Jessie with the most recent updates.

raveit65 commented 8 years ago

permission probs with /run/user/1000/dconf/user is an very old systemd/pam prob, see https://bugzilla.redhat.com/show_bug.cgi?id=753882 I suggest to bother the real culprit.

CoolAller commented 8 years ago

This error was before Systemd - using 100% CPU and memory leak, even when using sysvinit. So I wouldn't say that to blame systemd.

raveit65 commented 8 years ago

i only mentioned permission probs with /run/user/1000/dconf/user, which is well known prob with systemd

CoolAller commented 8 years ago

Thanks for the reply! There is at least some information about what it is someone is going to fix in systemd?

usmarine2141 commented 8 years ago

There is memory leak still going on. using 30gb of RAM and only have 1 terminal, sys monitor, FF open up. any idea when this will be fixed?

CoolAller commented 8 years ago

@usmarine2141, I created a bug report on the Debian's bug tracking system.There I was told that the problem is not related to systemd. Debian's support said that the alleged need to make corrections in sudo. In any case, the error is not corrected to this day and I think it will not be fixed ever, since this issue has a lot of years and no one wants to solve it. Unfortunately I do not have sufficient competence to solve the problem yourself.

Developers of Linux Mint have decided to fix the bug themselves and posted a patch here: https://github.com/linuxmint/systemd-betsy/commit/f7ab85f1e1169ac1598dfc1fba1c01063840b3c5

If you are like me using Debian 8 Jessie, I can share the collected packets with applying the patch: systemd_215-17+deb8u3_amd64: https://yadi.sk/d/EPyCNwF5rczCP systemd_215-17+deb8u3_i386: https://yadi.sk/d/1iNA4JrxrczCF md5sums systemd_215-17+deb8u3_amd64: https://yadi.sk/d/gLb5tf3qrd3DR md5sums systemd_215-17+deb8u3_i386: https://yadi.sk/d/Ks4oJr5Drd3DP

I hope it will help someone.

linas commented 8 years ago

@CoolAller can you share the Debian ticket number with us? I thought I described the problem quite closely, in https://github.com/mate-desktop/mate-settings-daemon/issues/44#issuecomment-61430431 and https://github.com/mate-desktop/mate-settings-daemon/issues/44#issuecomment-61431329 and I'm thinking that the Debian maintainer(s) did not see these and/or did not understand the nature of the bug.

linas commented 8 years ago

FWIW, besides the patch linuxmint/systemd-betsy@f7ab85f mentioned above, it is also claimed that https://cgit.freedesktop.org/systemd/systemd/commit/?id=baae0358f349870544884e405e82e4be7d8add9f fixes the bug, but this is not entirely clear. The debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766464 was closed, based on that claim, so if the bug is still recurring, then the bug report was incorrectly closed.

mate-desktop / mate-settings-daemon

memory usage #44