On 2013-01-09 19:41, fred smith wrote:
> here's the (I think) equivalent blocks from my system:
>
> 08048000-0805b000 r-xp 00000000 fd:00 4685290 /usr/libexec/clock-applet
> Size: 76 kB
> Rss: 68 kB
> Shared_Clean: 0 kB
> Shared_Dirty: 0 kB
> Private_Clean: 68 kB
> Private_Dirty: 0 kB
> Swap: 0 kB
> Pss: 68 kB
> 0805b000-0805c000 rw-p 00012000 fd:00 4685290 /usr/libexec/clock-applet
> Size: 4 kB
> Rss: 4 kB
> Shared_Clean: 0 kB
> Shared_Dirty: 0 kB
> Private_Clean: 0 kB
> Private_Dirty: 4 kB
> Swap: 0 kB
> Pss: 4 kB
> 09681000-1072a000 rw-p 09681000 00:00 0 [heap]
> Size: 115364 kB
> Rss: 115288 kB
> Shared_Clean: 0 kB
> Shared_Dirty: 0 kB
> Private_Clean: 0 kB
> Private_Dirty: 115288 kB
> Swap: 0 kB
> Pss: 115288 kB
>
> I note that the heap shows 115288, or around 115 megabytes.
> Do I understand what you said (below) to imply that in this example, clock-applet is directly
> responsible for all 115288 KB, since Pss and RSS are the same?
Yes indeed. The heap is using an enourmous amount of memory there.
And it is all private data used by this program all by itself.
The heap space is mostly used by malloc and related programs.
So that points to some memory leak there.
What else could use the heap besides malloc? I'm not sure here.
A clock applet is of course very busy with time handling, and I guess,
does use some feature to get awakened now and then to update what it is
supposed to keep track of. Alarm interrrupts, sleeps etc.
And malloc inside an interrupt handler could have such an effect.
You could try to see if there is a correlation of that heap space size
with time. Is it linear? Or does it increase more in certain situations
(heavy CPU usage, heavy disk usage, when you have a VM-client running
on the system at the same time,...)?
I've not looked into the source code of the clock applet.
Neither do I have an explanation why the problem disappears some
time later, as many people have observed, and as happend on my system too.
Was that due to an upgrade of some package? Or due to a different
sequence of events that happen to free after the malloc in the
right order?.
I guess you are sure you're running all programs updated to the current 5.8 version.
> top currently
> shows:
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP CODE DATA nFLT nDRT COMMAND
> 23350 fredex 16 0 240m 124m 9.9m S 0.7 3.2 1:25.71 115m 76 125m 1 0 clock-applet
>
> note that I've enabled some other memory-related columns here. I think it may be
> interesting to see that the swap amount appears to be the same as (or at least close)
> the size/rss/private-dirty/pss entries from the [heap] section shown above.
In modern Linux, I understand, the notion of swap, as we learned it from the early days
is heavily changed. I'm not sure anymore if swap here means: paged out to swap space,
or reserved in swap space, or something else.
The DATA is indeed 125m, and that is indeed the heap above.
> Another thing that might be interesting to try is to kill the clock-applet and leave it
> dead for a while, and see if top starts reporting that memory to some other app(let).
That would then verify the claim that the leak is not real (the above shows the contrary,
I think), and gnome programs interact with each other in much more deeper ways than
you would expect.
--
Paul Bijnens, Xplanation
***********************************************************************
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, ~., *
* stop, end, ^]c, +++ ATH, disconnect, halt, abort, hangup, KJOB, *
* ^X^X, :D::D, kill -9 1, kill -1 $$, shutdown, init 0, Alt-F4, *
* Alt-f-e, Ctrl-Alt-Del, Alt-SysRq-reisub, Stop-A, AltGr-NumLock, ... *
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***********************************************************************
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
