[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Dealing with a memory leak
From:       Anne Wilson <cannewilson () googlemail ! com>
Date:       2009-11-22 10:23:49
Message-ID: 200911221023.49583.cannewilson () googlemail ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 21 November 2009 17:38:43 Lubos Lunak wrote:
>  In short: It's the Linux kernel's fault and it horribly sucks at this.
>  The  system becomes unresponsible because with memory full the system get
>  completely busy with just moving things between RAM and disk (swap), and
>  one of the things that is broken is that the kernel needs ages to realize
>  that something is wrong. As soon as it eventually manages to find out, OOM
>  (Out Of Memory) killer is started to pick a process to be killed, which
>  should remedy the situation. Here again it needs quite a while to make up
>  its mind and (especially with KDE) it often decides to kill completely
>  innocent vital processes first. It's been broken like this for ages and
>  apparently nobody capable of fixing it cares :(.
> 
>  Before rebooting, you can try using SysRq+F to manually trigger the OOM 
> killer, which should save some time. We have a hack in kdelibs to protect 
> kdeinit (which often used to be the target), but basically there's no good 
> workaround.
> 
I'll try that next time - although getting it to accept any keyboard input is 
extremely difficult.

>  If you know what process is likely to cause this, you can also run it with
>  a  memory limit set using 'ulimit'.
> 
Can you give me a bit more detail?  If it *is* nspluginviewer that triggers 
it, for instance, what do I need to do to set that limit?

The worst thing is that once the problem has been triggered you can't stop it.  
I can use firefox or konqueror for a long time without any problem at all as 
long as nspluginviewer doesn't kick in.  I've started killing it as soon as I 
leave the page that needed it, but although the leak slows, it doesn't free up 
anying, and the leak seems to be simply slowed, not stopped.

Top, on this laptop, normally shows a healthyamount of RAM free with little or 
no swap usage.  At the moment, for instance, it shows

Mem:  	2061316k total, 	1989632k used, 	 71684k free
Swap:	1052216k total,	553948k used,	498168k free

It moved to this position in just the few minutes I was viewing an embedded 
video.

At this I can go on using it for some time, but clearly the problem has been 
triggered, so I'll need to keep an eye on it so that I can bail out before I 
lose work.

Anne
-- 
KDE Community Working Group
New to KDE4? - get help from http://userbase.kde.org

["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]