I'm using XFCE 4.6.0 on a x86_64 machine with 8 GB RAM running ArchLinux. When running for a few days, xfwm4 suddenly starts allocating more and more memory until it gets killed by the oom-killer of the linux kernel. Maybe it might be helpful to know that I'm using a dual screen setup (1920x1200 + 1280x1024) with an NVidia graphics adapter using the closed-source nvidia driver. I have enabled the composite extension of XFCE.
I am running xfwm4 with Xinerama and NVidia prop driver using compositing and have uptimes of months w/out login out. I would rather focus on the "suddenly" aspect of the problem, it could be that one particular application that you run (or that is launched automatically) triggers the problem. Can you narrow down the scope of the problem, would it be possible for you to provide the /var/log/messages of your system? Can you list the processes running at the time of the issue? Can you also run xfwm4 in valgrind, that would help catching a potential leak?
Created attachment 2274 the message log In this case I was able to manually kill xfwm4 before more apps would have been killed. I've replaced xfwm4 with openbox for the moment. Since then everything works fine so far, but I would prefer using xfwm4 again, when possible. Oh, btw this memory leak seems to occur only when NOT working at the computer (at least that's what I remember), meaning the computer is more or less idle with monitors in power saving mode. At the time xfwm4 started to use all my memory again, I noticed that because of the hard disk activity. I was able to login from another computer via ssh and kill xfwm4 which was using more than 7000 MB of RAM at that time already. Applications which were running all the times the bug occured are: Xorg of course, Pidgin 2.5.5, XChat 2.8.6, Xscreensaver with blank screen only, Orage and GKrellm 2.3.2. Also at least one XFCE Terminal was running all the time as well as the XFCE components such as the desktop manager. As a loginn manager I'm running slim. Other applications (mostly Firefox and some text editor) have been running but those were not running all the times when the xfwm4 memory bug occured. As system daemons there were the udevd, syslog-ng, dhcpcd, crond, sshd, cupsd, hald and dbus-daemon running.
The log shows oom_killer killing firefox and xmms, I do not see xfwm4 being killed here. I am not seeing any swap on your system, you should have some swap (that might explain why OOM get triggered) Anyway, I need to have a valgrind log otherwise there is no chance to trace back a potential memory leak.
As I said before, here I was there in the right second, so that I was able to manually kill xfwm4 before it was killed itself. I don't have the logs of the previous situations anymore. The oom-killer chooses almost randomly applications to kill. That does not mean Firefox or XMMS were causing the problem. This was not the case. And besides, this happend before without using XMMS and Firefox. I don't need any swap. I have intentionally disabled it and never ever had such problems before, not even with xfwm4 from XFCE 4.4. The missing swap is NOT the cause for the oom-killer bein invoked. xfwm4 was using more than 7 GB of memory which I believe is way above an acceptable memory usage. Other people do not even have 8 GB memory including swap, so I'm pretty sure 8 GB total should be more than enough.
As for running xfwm in valgrind: When I find some time to do that. I'll do it, but unfortunately I need the computer for work. So I can't run xfwm4 in valgrind for some days right now.
(In reply to comment #4) > As I said before, here I was there in the right second, so that I was able to > manually kill xfwm4 before it was killed itself. I don't have the logs of the > previous situations anymore. The oom-killer chooses almost randomly > applications to kill. No, that is not correct, OOM does not choose a random application to kill, there is a pretty smart algorithm to select which process slligible to kil. If you have random apps being killed, it denotes another serious problem on your system. [...] > I don't need any swap. I have intentionally disabled it and never ever had such > problems before, not even with xfwm4 from XFCE 4.4. The missing swap is NOT the > cause for the oom-killer bein invoked. xfwm4 was using more than 7 GB of memory > which I believe is way above an acceptable memory usage. Other people do not > even have 8 GB memory including swap, so I'm pretty sure 8 GB total should be > more than enough. Again, this assumption is not entirely correct, Linux will need swap in its default setup, unless you tweak the vm. I would definitely advise using swap, even with 8 Gb (that's not *that* much anyway). Some would not even support a configuratio nw/out swap, for good reasons. > As for running xfwm in valgrind: When I find some time to do that. I'll do it, > but unfortunately I need the computer for work. So I can't run xfwm4 in > valgrind for some days right now. And I cannot fix an issue without any data, so status quo.
> No, that is not correct, OOM does not choose a random application to kill, > there is a pretty smart algorithm to select which process slligible to kil. If > you have random apps being killed, it denotes another serious problem on your > system. I know that it does not choose the applications it kills really randomly, but it always chooses the wrong applications as it simply can't know which are important to the user. Well except maybe Xorg, which it usually does not kill in the first place. It is far from smart, however. It should rather kill the application which is increasing its memory usage at an alarming rate, but it does not work that way. > Again, this assumption is not entirely correct, Linux will need swap in its > default setup, unless you tweak the vm. I would definitely advise using swap, > even with 8 Gb (that's not *that* much anyway). I did not say that it is very much, but currently it is more than the average computer has and more importantly it has always been more than enough for me. > Some would not even support a configuratio nw/out swap, for good reasons. No, there is no good reason to have swap, except when you don't have enough RAM, at least for me. I do not want any applications to be swapped out to disk. Never ever. So having swap enabled is not even an option. No buffers which the kernel might use the RAM it could free by swapping out some applications can give me such an advantage that it would make it acceptable foor me to wait for an swapped out application to be loaded back to memory when I need it again. I want all applications to appear as fast as possible. I know how Linux handles virtual memory, and I know that it over commits memory, but all this should not be the problem here. No application should use that much RAM. It should especially not allocate huge amounts of virtual memory, when it does not really need that much and I doubt xfwm really needed that much memory. Especially a window manager should use as few ressources as possible. > And I cannot fix an issue without any data, so status quo. Well, so be it. I was asking on the IRC channel about this issue and someone asked me to open a bug for that, which I did. I gave you as much information as I could, but I just don't have the time to play around with this for days. This is not a toy for me. I'm happy to give you more information which might be helpful, as long it does not keep me from working with my computer. Running xfwm4 in valgrind obviously would - I would need to run it for several days and running an application in a memory debugger like valgrind makes it so much slower that you can't really work with that.
Hi, It appears this bug report does not have data that can be acted upon by Olivier. I suggest this report should be closed for now as no similar reports appear to have been made in the past few years. Original reporter, if you are still experiencing this issue could you please reopen the report? Any information you can provide (including the full list of applications you run, your exact hardware and driver version numbers, exact version numbers of Xfce, X11 and other core libraries, especially as you're on a rolling distro) might help in the future, although the only sure way to fix this bug is a Valgrind log.
Agreed, closing for now.