Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-13 Thread Nicolas Thierry-Mieg
Gordon Messmer wrote:

 To debug the clock applet, first you'd have to kill it, and then start
 it under valgrind:
 valgrind -v --log-file=/var/tmp/clock-applet.log clock-applet

you probably want to add --leak-check=full
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-12 Thread Gordon Messmer
On 01/08/2013 05:25 AM, Paul Bijnens wrote:
 Then I fell over:

 https://blogs.oracle.com/bnitz/entry/thanks_for_the_memories
 https://live.gnome.org/MemoryReduction

 which seems to imply that the shared libraries of all stuff used by Gnome
 gets measured in one of the gnome programs, frequently the clock-applet
 apparently.

 That implies that this problem is a red herring. I just means that during
 the lifetime of Gnome, there were lots of shared libraries loaded, and that
 memory shows up for 1 applet only.

It doesn't imply that at all.  Shared memory use is reported as RES for 
all of the applications that load the shared libraries.  It's not just 
for one of them.

Since shared libraries are also loaded when the application starts, RES 
will normally start out large for applications so affected.  When RES 
grows over time, without bound, it's probably an actual memory leak.

To debug the clock applet, first you'd have to kill it, and then start 
it under valgrind:
   valgrind -v --log-file=/var/tmp/clock-applet.log clock-applet

Let it run until you believe it has leaked memory, then kill it again. 
The log file should have details about any detected memory leaks.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-10 Thread Paul Bijnens


On 2013-01-09 19:41, fred smith wrote:
 here's the (I think) equivalent blocks from my system:

 08048000-0805b000 r-xp  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 %MEMTIME+  SWAP CODE DATA 
 nFLT nDRT COMMAND
 23350 fredex16   0  240m 124m 9.9m S  0.7  3.2   1:25.71 115m   76 125m   
  10 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@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-10 Thread Les Mikesell
On Thu, Jan 10, 2013 at 2:13 AM, Paul Bijnens
paul.bijn...@xplanation.com wrote:

 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.

I sort-of remember once having evolution hooked to an exchange server
and the clock applet seemed to be aware of all of my exchange calendar
events but it was really too buggy to use back then.   Do you have any
calendar settings that any gnome program knows about?

-- 
   Les Mikesell
  lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-10 Thread fred smith
On Thu, Jan 10, 2013 at 08:10:43AM -0600, Les Mikesell wrote:
 On Thu, Jan 10, 2013 at 2:13 AM, Paul Bijnens
 paul.bijn...@xplanation.com wrote:
 
  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.
 
 I sort-of remember once having evolution hooked to an exchange server
 and the clock applet seemed to be aware of all of my exchange calendar
 events but it was really too buggy to use back then.   Do you have any
 calendar settings that any gnome program knows about?

not sure what those settings might be, to which you refer. there aren't
very many settings available in the clock applet.

also, I don't use/like evolution.



-- 
 Fred Smith -- fre...@fcshome.stoneham.ma.us -
The Lord is like a strong tower. 
 Those who do what is right can run to him for safety.
--- Proverbs 18:10 (niv) -
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-10 Thread Paul Bijnens



On 2013-01-10 15:10, Les Mikesell wrote:
 On Thu, Jan 10, 2013 at 2:13 AM, Paul Bijnens
 paul.bijn...@xplanation.com  wrote:

 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.

 I sort-of remember once having evolution hooked to an exchange server
 and the clock applet seemed to be aware of all of my exchange calendar
 events but it was really too buggy to use back then.   Do you have any
 calendar settings that any gnome program knows about?



I did not have items in some calendar. I do not run Evolution, it is not even
installed anymore. Maybe I had it installed at some time, but just yum erase-d
it at some point. I've never even started it once on this workstation.

I hate calendars (with deadlines and due dates just wooshing by).

I do have the Lightning plugin in Thunderbird, just to be able to read
nice formatted invites to meetings etc. And that thing marks items in my 
calendar.

And I do remember having difficulties to install a working version of
Lightning due to 32/64 bit problems at that time.

I think had to install a 32 bit version of TB on my 64bit workstation to be able
to use it then.
But when TB 10 replaced the TB 2 (or was that TB 3?), I just trow out all of it,
and installed the standard CentOS TB 10. Even the Lightning plugin works now 
too.

Maybe that was around the time when I noticed my memory problem with the 
clock-applet
disappeared?  I not sure anymore.

I just mention this because I noticed that Fred also was experimenting with
Firefox 18.  And until a real cause of the problem is found, everything is 
suspect.


-- 
Paul Bijnens, XplanationTel  +32 16 397.525
Interleuvenlaan 86, B-3001 Leuven, BELGIUM  Fax  +32 16 397.552
***
* 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@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-10 Thread Les Mikesell
On Thu, Jan 10, 2013 at 12:03 PM, Paul Bijnens
paul.bijn...@xplanation.com wrote:

 I do have the Lightning plugin in Thunderbird, just to be able to read
 nice formatted invites to meetings etc. And that thing marks items in my 
 calendar.

If you have notifications set, does the clock-applet pop them up?

 And I do remember having difficulties to install a working version of
 Lightning due to 32/64 bit problems at that time.

 I think had to install a 32 bit version of TB on my 64bit workstation to be 
 able
 to use it then.
 But when TB 10 replaced the TB 2 (or was that TB 3?), I just trow out all of 
 it,
 and installed the standard CentOS TB 10. Even the Lightning plugin works now 
 too.

 Maybe that was around the time when I noticed my memory problem with the 
 clock-applet
 disappeared?  I not sure anymore.

 I just mention this because I noticed that Fred also was experimenting with
 Firefox 18.  And until a real cause of the problem is found, everything is 
 suspect.

I don't know anything about the mechanisms involved, but the
clock-applet seemed to be aware of other stuff - and probably consumes
memory in the process.   The 6.x version also has a weather-checker in
there.

-- 
   Les Mikesell
 lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-10 Thread Paul Bijnens


On 2013-01-10 19:13, Les Mikesell wrote:
 On Thu, Jan 10, 2013 at 12:03 PM, Paul Bijnens
 paul.bijn...@xplanation.com  wrote:

 I do have the Lightning plugin in Thunderbird, just to be able to read
 nice formatted invites to meetings etc. And that thing marks items in my 
 calendar.

 If you have notifications set, does the clock-applet pop them up?

No popops by the calendar (but I do not have the memory leak problem anymore 
either).
Maybe I did had some experiments in that time when testing Lightning then.


 I don't know anything about the mechanisms involved, but the
 clock-applet seemed to be aware of other stuff - and probably consumes
 memory in the process.   The 6.x version also has a weather-checker in
 there.


Wow, now, that you say it... Now I have a remote temperature sensor
in CentOS 6.  My smartphone has one too :-)



-- 
Paul Bijnens, XplanationTel  +32 16 397.525
Interleuvenlaan 86, B-3001 Leuven, BELGIUM  Fax  +32 16 397.552
***
* 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@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-09 Thread ken
On 01/08/2013 08:25 AM Paul Bijnens wrote:


 On 2013-01-06 23:18, fred smith wrote:
 On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote:
 On 01/06/2013 09:55 AM fred smith wrote:
 On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:
 Fred,

 Also running an up-to-date 5.8 but with just 2G of RAM, clock-applet
 consumes the following:

 PID USER PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 4133 me  15   0 29568 3748 2944 S  0.0  0.2 190:51.33 clock-applet

 My uptime at the moment is coming on 68 days.  Over time the %CPU field
 may flicker up to 0.3 or even 0.7, but the RES column and others are
 steady at the numbers you see.  I should add that all Preferences which
 we'd expect to consume more resources (e.g., display seconds, 12-hour
 time) are on.
 [...]

 here's what top reports today (clock-applet has not been restarted since
 the event mentioned in my original posting):

 PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 11159 fredex16   0  263m 149m  10m S  0.3  3.8   1:36.87 clock-applet

 in which I note it is now up to 149m.


 I had that problem also a few years back (CentOS 5.1, 5.2 or so).
 When Googling for it, I had found several bug reports about it.
 While some of those bug reports had some fixes in a future version
 mentioned, other bugreports mentioned that the problem disappeared
 all by itself.

 And indeed, for me too, some upgrades later, the problem disappeared
 for me too.

 Then I fell over:

 https://blogs.oracle.com/bnitz/entry/thanks_for_the_memories
 https://live.gnome.org/MemoryReduction

 which seems to imply that the shared libraries of all stuff used by Gnome
 gets measured in one of the gnome programs, frequently the clock-applet
 apparently.

 That implies that this problem is a red herring. I just means that during
 the lifetime of Gnome, there were lots of shared libraries loaded, and that
 memory shows up for 1 applet only.

 And, yes indeed, looking carefully I notice that now the black sheep getting
 all the blame is the wnck-applet for me currently, instead of the 
 clock-applet.
 It's using 342m memory now (68 days uptime, without logout of gnome).

 And yes, googling for wnck-applet memory instead of clock-applet memory
 brings up a very similar list of bug reports, also telling sometimes it the
 problem disappeared all by itself.

 To find out which libraries all get counted for the clock-applet,
 run pmap -x PID-of-clock-applet on regular times, and see where the
 increase in memory is coming from.

Paul,

Excellent!  Thanks for unraveling the mystery.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-09 Thread fred smith
On Wed, Jan 09, 2013 at 04:31:55AM -0500, ken wrote:
 On 01/08/2013 08:25 AM Paul Bijnens wrote:

My thanks to Ken, Paul, and all the others who have replied to this thread.
I haven't had time to dig into it over the last couple of days, but once
I have worked thru all your suggestions I'll try to remember to post an
update here.

thanks again!

Fred

 
 
  On 2013-01-06 23:18, fred smith wrote:
  On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote:
  On 01/06/2013 09:55 AM fred smith wrote:
  On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:
  Fred,
 
  Also running an up-to-date 5.8 but with just 2G of RAM, clock-applet
  consumes the following:
 
  PID USER PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
  4133 me  15   0 29568 3748 2944 S  0.0  0.2 190:51.33 clock-applet
 
  My uptime at the moment is coming on 68 days.  Over time the %CPU field
  may flicker up to 0.3 or even 0.7, but the RES column and others are
  steady at the numbers you see.  I should add that all Preferences which
  we'd expect to consume more resources (e.g., display seconds, 12-hour
  time) are on.
  [...]
 
  here's what top reports today (clock-applet has not been restarted since
  the event mentioned in my original posting):
 
  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
  11159 fredex16   0  263m 149m  10m S  0.3  3.8   1:36.87 clock-applet
 
  in which I note it is now up to 149m.
 
 
  I had that problem also a few years back (CentOS 5.1, 5.2 or so).
  When Googling for it, I had found several bug reports about it.
  While some of those bug reports had some fixes in a future version
  mentioned, other bugreports mentioned that the problem disappeared
  all by itself.
 
  And indeed, for me too, some upgrades later, the problem disappeared
  for me too.
 
  Then I fell over:
 
  https://blogs.oracle.com/bnitz/entry/thanks_for_the_memories
  https://live.gnome.org/MemoryReduction
 
  which seems to imply that the shared libraries of all stuff used by Gnome
  gets measured in one of the gnome programs, frequently the clock-applet
  apparently.
 
  That implies that this problem is a red herring. I just means that during
  the lifetime of Gnome, there were lots of shared libraries loaded, and that
  memory shows up for 1 applet only.
 
  And, yes indeed, looking carefully I notice that now the black sheep getting
  all the blame is the wnck-applet for me currently, instead of the 
  clock-applet.
  It's using 342m memory now (68 days uptime, without logout of gnome).
 
  And yes, googling for wnck-applet memory instead of clock-applet memory
  brings up a very similar list of bug reports, also telling sometimes it the
  problem disappeared all by itself.
 
  To find out which libraries all get counted for the clock-applet,
  run pmap -x PID-of-clock-applet on regular times, and see where the
  increase in memory is coming from.
 
 Paul,
 
 Excellent!  Thanks for unraveling the mystery.
 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos

-- 
 Fred Smith -- fre...@fcshome.stoneham.ma.us -
Not everyone who says to me, 'Lord, Lord,' will enter the kingdom of
 heaven, but only he who does the will of my Father who is in heaven.
-- Matthew 7:21 (niv) -
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-09 Thread Paul Bijnens

I'm still not really out of the problem either:

On 2013-01-09 14:21, fred smith wrote:
  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
11159 fredex16   0  263m 149m  10m S  0.3  3.8   1:36.87 clock-applet

263m VIRT: We understand that virtual memory is sum of all, including the read
only/executable parts of lots of shared libraries which are not using many
resources in fact because they are backed by the real files.

149m RES: The parts that are really in use by this program, but including
the parts shared by many others of the Gnome package that are running.
(I put this between quotes, because someone seemed to believe that
top or ps or some other program adds memory sizes in in unfair way
to some processes only, while they should have been distributed over many.
Actually I can't find any reason, or explanation of that.)

10m SHR:  of those 149m that are in use, 10m is the shared portion.

That leaves 139m allocated exclusively by the clock-applet.
Incredibly large yes.

What is that clock-applet doing with 139m?
Or is that just because you do have lots of RAM, and in fact, lots of those
pages could be swapped out (= for executables like shared libraries, just
be removed; they can be swapped in from the file itself), but never had to
be swapped out/deleted, because the OS still had unused pages.

I have rebooted my workstation (due to postponed kernel upgrade) yesterday.
I have now:

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
5908 paulb 15   0  283m  13m 9496 S  0.0  0.3   0:25.29 wnck-applet
5950 paulb 15   0  268m  10m 8968 S  0.0  0.3   0:54.00 clock-applet

and I can't find any process that is taking large amounts of memory.
Firefox  Thunderbird are using considerable amounts but not more than usual.
I did not run any real large program yet (swap use is 0 now), and did not
do heavy memory using programs except ff  tb.
So why is my RES on 10m now? Probably because the clock-applet did not
even touch more of the shared libraries (totaling 268m possibly being touched).

As I said, the problem of the large clock-applet magically disappeared for me
somewhere between 5.1 and 5.5 or so.
I remember fiddling with the seconds indicator, changing every option to 
default,
monitoring the mem over several weeks, seeing it increasing, but seeing no
trend/reason/cause. Gave up on searching intensly. And then some time later
noticed the problem disappeared.
Yesterday I thought wcnk-applet had the enormous amount of RAM, but I think
I was looking at the VIRT size only then.  VIRT is a useless indicator here.

Inspecting /proc/PID/smaps of such a large process may reveal something?


(Nostalgia: 1m private data for my running clock-applet still seems large to me,
remembering to program on a mainframe with a total memory of 12 Mbyte, 
supporting
hundreds of users. I remember it was upgraded to 16 Mbyte, the maximum
amount. That was larger than one of its hard disks of 6 or 10 Mbyte, the size
of a washing machine.)


-- 
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@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-09 Thread fred smith
On Wed, Jan 09, 2013 at 04:05:26PM +0100, Paul Bijnens wrote:
 
 I'm still not really out of the problem either:
 
 On 2013-01-09 14:21, fred smith wrote:
   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 11159 fredex16   0  263m 149m  10m S  0.3  3.8   1:36.87 clock-applet
 
 263m VIRT: We understand that virtual memory is sum of all, including the read
 only/executable parts of lots of shared libraries which are not using many
 resources in fact because they are backed by the real files.
 
 149m RES: The parts that are really in use by this program, but including
 the parts shared by many others of the Gnome package that are running.
 (I put this between quotes, because someone seemed to believe that
 top or ps or some other program adds memory sizes in in unfair way
 to some processes only, while they should have been distributed over many.
 Actually I can't find any reason, or explanation of that.)
 
 10m SHR:  of those 149m that are in use, 10m is the shared portion.
 
 That leaves 139m allocated exclusively by the clock-applet.
 Incredibly large yes.
 
 What is that clock-applet doing with 139m?

I find that to be a really good question. When I first posted, the system
had been up for (from my memory) something like 29 days, and the RES 
column for clock_applet was some number well above a gigabyte. I can imagine
that those who say it's just being reported wrong may be right, but if so
I don't see why that number would continue to grow. in fact it's also a
fact that the amount of swap in use had grown above two gigs, which is
definitely NOT the norm on this system. So I still think it's being
leaked, _somewhere_.

 Or is that just because you do have lots of RAM, and in fact, lots of those
 pages could be swapped out (= for executables like shared libraries, just
 be removed; they can be swapped in from the file itself), but never had to
 be swapped out/deleted, because the OS still had unused pages.
 
 I have rebooted my workstation (due to postponed kernel upgrade) yesterday.
 I have now:
 
   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 5908 paulb 15   0  283m  13m 9496 S  0.0  0.3   0:25.29 wnck-applet
 5950 paulb 15   0  268m  10m 8968 S  0.0  0.3   0:54.00 clock-applet
 
 and I can't find any process that is taking large amounts of memory.
 Firefox  Thunderbird are using considerable amounts but not more than usual.
 I did not run any real large program yet (swap use is 0 now), and did not
 do heavy memory using programs except ff  tb.
 So why is my RES on 10m now? Probably because the clock-applet did not
 even touch more of the shared libraries (totaling 268m possibly being 
 touched).
 
 As I said, the problem of the large clock-applet magically disappeared for me
 somewhere between 5.1 and 5.5 or so.
 I remember fiddling with the seconds indicator, changing every option to 
 default,
 monitoring the mem over several weeks, seeing it increasing, but seeing no
 trend/reason/cause. Gave up on searching intensly. And then some time later
 noticed the problem disappeared.
 Yesterday I thought wcnk-applet had the enormous amount of RAM, but I think
 I was looking at the VIRT size only then.  VIRT is a useless indicator here.
 
 Inspecting /proc/PID/smaps of such a large process may reveal something?

well, there's a LOT of stuff dumped when one cats the file. but I have
no adequate expertise to figure out what it all means.



-- 
 Fred Smith -- fre...@fcshome.stoneham.ma.us -
  The eyes of the Lord are everywhere, 
keeping watch on the wicked and the good.
- Proverbs 15:3 (niv) -
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-09 Thread Les Mikesell
On Wed, Jan 9, 2013 at 9:05 AM, Paul Bijnens
paul.bijn...@xplanation.com wrote:

 On 2013-01-09 14:21, fred smith wrote:
  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
11159 fredex16   0  263m 149m  10m S  0.3  3.8   1:36.87 clock-applet


 149m RES: The parts that are really in use by this program, but including
 the parts shared by many others of the Gnome package that are running.
 (I put this between quotes, because someone seemed to believe that
 top or ps or some other program adds memory sizes in in unfair way
 to some processes only, while they should have been distributed over many.
 Actually I can't find any reason, or explanation of that.)

 10m SHR:  of those 149m that are in use, 10m is the shared portion.

 That leaves 139m allocated exclusively by the clock-applet.
 Incredibly large yes.

I think the scenario is that you have large shared libraries that
other programs _could_ ahare but at the moment you don't have other
running applications that actually are sharing the code..

 (Nostalgia: 1m private data for my running clock-applet still seems large to 
 me,
 remembering to program on a mainframe with a total memory of 12 Mbyte, 
 supporting
 hundreds of users. I remember it was upgraded to 16 Mbyte, the maximum
 amount. That was larger than one of its hard disks of 6 or 10 Mbyte, the size
 of a washing machine.)

Think in terms of dollars instead of Mbytes here and it will make more
sense that nobody cares anymore.

-- 
Les Mikesell
   lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-09 Thread m . roth
Les Mikesell wrote:
 On Wed, Jan 9, 2013 at 9:05 AM, Paul Bijnens
 paul.bijn...@xplanation.com wrote:

 On 2013-01-09 14:21, fred smith wrote:
  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
11159 fredex16   0  263m 149m  10m S  0.3  3.8   1:36.87
 clock-applet


 149m RES: The parts that are really in use by this program, but
 including the parts shared by many others of the Gnome package that are
running.
 (I put this between quotes, because someone seemed to believe that
 top or ps or some other program adds memory sizes in in unfair way
 to some processes only, while they should have been distributed over
 many. Actually I can't find any reason, or explanation of that.)

 10m SHR:  of those 149m that are in use, 10m is the shared portion.

 That leaves 139m allocated exclusively by the clock-applet.
 Incredibly large yes.
snip
 (Nostalgia: 1m private data for my running clock-applet still seems
 large to me, remembering to program on a mainframe with a total
 memory of 12 Mbyte, supporting hundreds of users. I remember it was
 upgraded to 16 Mbyte, the maximum amount. That was larger than one
 of its hard disks of 6 or 10 Mbyte, the size of a washing machine.)

Yup. Of course, the punch cards did take up a lot of space I remember
carrying boxes in college.

It still bothers me to align the new large disks on 1M or 2M boundaries,
loosing that much disk space; I do remember wanting to kill for one of the
5M h/d's that had just come out for PCs

 Think in terms of dollars instead of Mbytes here and it will make more
 sense that nobody cares anymore.

You ain't got no sense o' history or wonder, Les.

   mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-09 Thread Les Mikesell
On Wed, Jan 9, 2013 at 10:16 AM,  m.r...@5-cent.us wrote:

 Think in terms of dollars instead of Mbytes here and it will make more
 sense that nobody cares anymore.

 You ain't got no sense o' history or wonder, Les.


Oh, the days of wooden computers and iron programmers... I've been
there, done that, and didn't like it much.  Per-program memory bloat
doesn't bother me nearly as much as the idea of having dozens of
different shared libraries that all provide the same functionality but
aren't compatible and thus aren't actually shared (and worse, all have
different bugs to deal with).  Or that it is so difficult and unusual
to run multiple X desktops from the same host where all the code space
would automatically be shared by all instances (in the unlikely event
that they ran the same desktop flavor...).  Or that a 'modern' system
will need support for a dozen or more different programming languages
and all their associated libraries none of which will share disk or
RAM..  Or that even though the slowest computer operation for decades
has been moving a disk head, operating systems are still to dumb to
move frequently accessed things to nearby locations.

-- 
   Les Mikesell
 lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-09 Thread Paul Bijnens


On 2013-01-09 16:50, fred smith wrote:
 On Wed, Jan 09, 2013 at 04:05:26PM +0100, Paul Bijnens wrote:
 Inspecting /proc/PID/smaps of such a large process may reveal something?

 well, there's a LOT of stuff dumped when one cats the file. but I have
 no adequate expertise to figure out what it all means.


What I know about it...

Here are some lines from my running system (first 3 blocks only):

0040-00414000 r-xp  fd:00 190374 
/usr/libexec/clock-applet
Size:80 kB
Rss: 72 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean:   72 kB
Private_Dirty:0 kB
Swap: 0 kB
Pss: 72 kB
00614000-0061b000 rw-p 00014000 fd:00 190374 
/usr/libexec/clock-applet
Size:28 kB
Rss: 16 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean:   12 kB
Private_Dirty:4 kB
Swap: 0 kB
Pss: 16 kB
14c9e000-14ea3000 rw-p 14c9e000 00:00 0  [heap]
Size:  2068 kB
Rss:   2064 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean:0 kB
Private_Dirty: 2064 kB
Swap: 0 kB
Pss:   2064 kB


That shows 3 memory blocks.

The first two blocks are from the program file itself 
/usr/libexec/clock-applet.

The first block of that is not writable (r-xp). That are the executable 
instructions.
The second one is writable (rw-p). Those are the writable data (variable 
etc.).

We see several sizes. We see the total size, and the RSS size (=what is
using memory now).  The RSS is again split up in different categories below it.
(Shared/Private Clean/dirty).

The first block is the code, and thus non writable, and thus pages here can be 
deleted
from memory at all times and can be paged back in from the file itself. They 
should always
have 0 dirty pages.
The second block is writable, having a mix of clean and dirty pages.
These dirty pages must always be kept in memory.
Dirty pages can also be shared with other processes, e.g. shmem segments.


Next we see the heap (memory from malloc etc). And as expected, all private
and dirty here.


When a page is shared between many processes, this is reflected in the PSS value
(proportional set size):  64 kB RSS, all shared between 4 processes, will show 
16 kB PSS.

Example:
2d317000-2d346000 r-xp  fd:00 189693 
/usr/lib64/libgsf-1.so.114.0.1
Size:   188 kB
Rss: 56 kB
Shared_Clean:48 kB
Shared_Dirty: 0 kB
Private_Clean:8 kB
Private_Dirty:0 kB
Swap: 0 kB
Pss: 21 kB

# lsof /usr/lib64/libgsf-1.so.114.0.1
COMMAND PID  USER  FD   TYPE DEVICE SIZE/OFF   NODE NAME
gnome-pan  5826 paulb memREG  253,0   210712 189693 
/usr/lib64/libgsf-1.so.114.0.1
stickynot  5932 paulb memREG  253,0   210712 189693 
/usr/lib64/libgsf-1.so.114.0.1
clock-app  5950 paulb memREG  253,0   210712 189693 
/usr/lib64/libgsf-1.so.114.0.1
nautilus  23427 paulb memREG  253,0   210712 189693 
/usr/lib64/libgsf-1.so.114.0.1

Apparently not all 56kB is shared with all these 4 processes, but 
proprotionally the clock
is using 21 kB of that.


The ps and top show the sum of several of those values:
VIRT: sum of Size
RSS : sum of Rss
SHR : sum of Shared_*
(aproximately at least: When I do my additions, I get in the neighbourhood, but 
not exact.
I do not know why...)

So to debug our problem, we should find some part(s) there and see where the
memory is going to.
Maybe there is 1 large part? (e.g. some enormous font
file -- unicode font -- that somehow all is marked as dirty)
Or many smaller parts (heap - mostly malloc and friends, and thus suspecting a
memory leak there).


-- 
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@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-09 Thread fred smith
On Wed, Jan 09, 2013 at 07:07:15PM +0100, Paul Bijnens wrote:
 
 
 On 2013-01-09 16:50, fred smith wrote:
  On Wed, Jan 09, 2013 at 04:05:26PM +0100, Paul Bijnens wrote:
  Inspecting /proc/PID/smaps of such a large process may reveal something?
 
  well, there's a LOT of stuff dumped when one cats the file. but I have
  no adequate expertise to figure out what it all means.
 
 
 What I know about it...
 
 Here are some lines from my running system (first 3 blocks only):
 
 0040-00414000 r-xp  fd:00 190374 
 /usr/libexec/clock-applet
 Size:80 kB
 Rss: 72 kB
 Shared_Clean: 0 kB
 Shared_Dirty: 0 kB
 Private_Clean:   72 kB
 Private_Dirty:0 kB
 Swap: 0 kB
 Pss: 72 kB
 00614000-0061b000 rw-p 00014000 fd:00 190374 
 /usr/libexec/clock-applet
 Size:28 kB
 Rss: 16 kB
 Shared_Clean: 0 kB
 Shared_Dirty: 0 kB
 Private_Clean:   12 kB
 Private_Dirty:4 kB
 Swap: 0 kB
 Pss: 16 kB
 14c9e000-14ea3000 rw-p 14c9e000 00:00 0  
 [heap]
 Size:  2068 kB
 Rss:   2064 kB
 Shared_Clean: 0 kB
 Shared_Dirty: 0 kB
 Private_Clean:0 kB
 Private_Dirty: 2064 kB
 Swap: 0 kB
 Pss:   2064 kB
 
 
 That shows 3 memory blocks.

here's the (I think) equivalent blocks from my system:

08048000-0805b000 r-xp  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?

top currently
shows:

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  SWAP CODE DATA 
nFLT nDRT COMMAND
23350 fredex16   0  240m 124m 9.9m S  0.7  3.2   1:25.71 115m   76 125m
10 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.

the other sections with large-ish values for 'size' are all in the 2x,xxx range 
or smaller--
mostly considerably smaller.

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).

 
 The first two blocks are from the program file itself 
 /usr/libexec/clock-applet.
 
 The first block of that is not writable (r-xp). That are the executable 
 instructions.
 The second one is writable (rw-p). Those are the writable data (variable 
 etc.).
 
 We see several sizes. We see the total size, and the RSS size (=what is
 using memory now).  The RSS is again split up in different categories below 
 it.
 (Shared/Private Clean/dirty).
 
 The first block is the code, and thus non writable, and thus pages here can 
 be deleted
 from memory at all times and can be paged back in from the file itself. They 
 should always
 have 0 dirty pages.
 The second block is writable, having a mix of clean and dirty pages.
 These dirty pages must always be kept in memory.
 Dirty pages can also be shared with other processes, e.g. shmem segments.
 
 
 Next we see the heap (memory from malloc etc). And as expected, all private
 and dirty here.
 
 
 When a page is shared between many processes, this is reflected in the PSS 
 value
 (proportional set size):  64 kB RSS, all shared between 4 processes, will 
 show 16 kB PSS.
 
 Example:
 2d317000-2d346000 r-xp  fd:00 189693 
 /usr/lib64/libgsf-1.so.114.0.1
 Size:   188 kB
 Rss: 56 kB
 Shared_Clean:48 kB
 Shared_Dirty: 0 kB
 Private_Clean:8 kB
 Private_Dirty:0 kB
 Swap: 0 kB
 Pss: 21 kB
 
 # lsof /usr/lib64/libgsf-1.so.114.0.1
 COMMAND PID  USER  FD   TYPE DEVICE SIZE/OFF   NODE NAME
 gnome-pan  5826 paulb memREG  253,0   210712 

Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-08 Thread Paul Bijnens


On 2013-01-06 23:18, fred smith wrote:
 On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote:
 On 01/06/2013 09:55 AM fred smith wrote:
 On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:
 Fred,

 Also running an up-to-date 5.8 but with just 2G of RAM, clock-applet
 consumes the following:

 PID USER PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 4133 me  15   0 29568 3748 2944 S  0.0  0.2 190:51.33 clock-applet

 My uptime at the moment is coming on 68 days.  Over time the %CPU field
 may flicker up to 0.3 or even 0.7, but the RES column and others are
 steady at the numbers you see.  I should add that all Preferences which
 we'd expect to consume more resources (e.g., display seconds, 12-hour
 time) are on.
[...]

 here's what top reports today (clock-applet has not been restarted since
 the event mentioned in my original posting):

PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 11159 fredex16   0  263m 149m  10m S  0.3  3.8   1:36.87 clock-applet

 in which I note it is now up to 149m.


I had that problem also a few years back (CentOS 5.1, 5.2 or so).
When Googling for it, I had found several bug reports about it.
While some of those bug reports had some fixes in a future version
mentioned, other bugreports mentioned that the problem disappeared
all by itself.

And indeed, for me too, some upgrades later, the problem disappeared
for me too.

Then I fell over:

https://blogs.oracle.com/bnitz/entry/thanks_for_the_memories
https://live.gnome.org/MemoryReduction

which seems to imply that the shared libraries of all stuff used by Gnome
gets measured in one of the gnome programs, frequently the clock-applet
apparently.

That implies that this problem is a red herring. I just means that during
the lifetime of Gnome, there were lots of shared libraries loaded, and that
memory shows up for 1 applet only.

And, yes indeed, looking carefully I notice that now the black sheep getting
all the blame is the wnck-applet for me currently, instead of the clock-applet.
It's using 342m memory now (68 days uptime, without logout of gnome).

And yes, googling for wnck-applet memory instead of clock-applet memory
brings up a very similar list of bug reports, also telling sometimes it the
problem disappeared all by itself.

To find out which libraries all get counted for the clock-applet,
run pmap -x PID-of-clock-applet on regular times, and see where the
increase in memory is coming from.

-- 
Paul Bijnens
***
* 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@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-08 Thread John Doe

Maybe try valgrind...
But after testing it on a few basic utilities like ls, find xclock, it seems 
that many of them do have leaks...

JD

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-08 Thread m . roth
John Doe wrote:

 Maybe try valgrind...
 But after testing it on a few basic utilities like ls, find xclock, it
 seems that many of them do have leaks...

More reason to dislike gnome

  mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-08 Thread Leon Fauster
Am 08.01.2013 um 16:19 schrieb m.r...@5-cent.us:
 John Doe wrote:
 
 Maybe try valgrind...
 But after testing it on a few basic utilities like ls, find xclock, it
 seems that many of them do have leaks...
 
 More reason to dislike gnome
 
  mark


confirmation bias - you only see what you want to see :-)

--
LF

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-08 Thread m . roth
Leon Fauster wrote:
 Am 08.01.2013 um 16:19 schrieb m.r...@5-cent.us:
 John Doe wrote:

 Maybe try valgrind...
 But after testing it on a few basic utilities like ls, find xclock, it
 seems that many of them do have leaks...

 More reason to dislike gnome

 confirmation bias - you only see what you want to see :-)

Along with bloat, and then there's things like trying to configure it
*bleah*. And I used to complain that to run kde, you needed a dozen things
running... at least kde acts the way I expect a GUI on a -UNIX--derived
o/s to work. Gnome, with its k3wl interface (don't start - I just
installed the latest fc17 on someone's workstation), and its menus that
wave, or the one on ubuntu that my stepson was using for a while, that
exploded when they went away

If you really, really want an o/s with a GUI accepted, make it acceptable
by businesses, where non-computerphiles learn to use 'em.

mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-07 Thread ken
 On Sun, Jan 06, 2013 at 06:23:20PM -0500, ken wrote:
 On 01/06/2013 05:18 PM fred smith wrote:
 On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote:
 On 01/06/2013 09:55 AM fred smith wrote:
 On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:
 Fred,

 Also running an up-to-date 5.8 but with just 2G of RAM, clock-applet
 consumes the following:

 PID USER PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 4133 me  15   0 29568 3748 2944 S  0.0  0.2 190:51.33 clock-applet

 My uptime at the moment is coming on 68 days.  Over time the %CPU field
 may flicker up to 0.3 or even 0.7, but the RES column and others are
 steady at the numbers you see.  I should add that all Preferences which
 we'd expect to consume more resources (e.g., display seconds, 12-hour
 time) are on.

 Do you use evolution?

 no, I have never found it to my liking.


 KDE, Gnome, or other WM?

 gnome.

 I don't know what to tell you then because, like you, I use gnome but
 not evolution.  So our systems-- what of them which are directly related
 to clock-applet-- are much the same, yet you have a memory problem with
 clock-applet which I don't.

 here's what top reports today (clock-applet has not been restarted since
 the event mentioned in my original posting):

 PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 11159 fredex16   0  263m 149m  10m S  0.3  3.8   1:36.87 clock-applet

 it's now up to 156m. :(


 in which I note it is now up to 149m.


 Here are some items to compare:

 # rpm -q gnome-panel
 gnome-panel-2.16.1-7.el5
 # ll /usr/libexec/clock-applet
 -rwxr-xr-x 1 root root 88048 May 24  2008 /usr/libexec/clock-applet
 # md5sum /usr/libexec/clock-applet
 9d21ca21a0e99ad26aa10e1cd5b42024  /usr/libexec/clock-applet

 # rpm -q gnome-panel
 gnome-panel-2.16.1-7.el5
 # ll /usr/libexec/clock-applet
 -rwxr-xr-x 1 root root 88048 May 24  2008 /usr/libexec/clock-applet
 # md5sum /usr/libexec/clock-applet
 2bc9a73a5251d1b4747ec133839412b7  /usr/libexec/clock-applet

 it's the same version and size as yours, but the md5sum differs. have
 you perhaps disabled prelink? (I don't call that I have ever done so)
 It's not obvious to me what other (legitimate) event would account for
 the difference in checksum.

 Take a look in /etc/sysconfig/prelink.  At the top it should tell you if
 you've got prelink on.  You should also have a file called prelink in
 /etc/cron.daily/.

 yes, it's on. there's a log in /var/log/prelink from just yesterday morning.

 wouldn't ya think that if prelink has modified it, that the rpm -V would
 have flagged a modified checksum? Or is prelink smart enuff to tweak
 the RPM database? I have no clue.

Think about what we've already discovered.  You and I have different 
results from md5sum, yet neither of our clock-applet files are flagged.
So we do have some kind of clue.  Without digging into code and running 
tests etc., I'm guessing that rpm must amend/revise its database 
contingent upon prelink's being invoked.



 If none of that explains things, you might want to just reinstall
 gnome-panel and see if that fixes the memory problem.

 might try that, though it pains me to have to resort to the sort of
 fixes that Windows folks think are normal: power off, power on: reinstall:
 reboot. Gah!
 :)

I know that feeling too.  But, first, you shouldn't have to reboot... 
probably not, because this gnome stuff should load only at runlevel 5. 
Trace out the init scripts if you want to be sure.  If so, that would 
mean you only need to init 2 (or maybe just 3); rpm -e gnome-panel; yum 
install gnome-panel; init 5.  That's really not very windozey.  You 
might also want to determine whether that command sequence will wipe 
your current panel configuration and, if so, which files to backup prior 
and restore later (so you wouldn't have to set up your panel all over 
again).  Do Windows folks do that?

1a:  It just occurred to me that (and this is a long shot, but still a 
possibility) the problem could go away just by reloading the applet. 
Just delete it from the panel and then install it again.  Then watch its 
memory consumption to see if there's a difference.  Even if this works, 
it likely wouldn't be anything more than a temporary fix, but it might 
point to where the problem lies.  And it's a real quick and easy.

Secondly, if the fate of the universe hung from our discovering exactly 
what the origin of the memory problem was, then yeah, it would be worth 
the effort.  But it doesn't.  There are lots of other and bigger issues 
around and dwelling on this little one would give people to think that 
we have too much time on our hands and that we don't know about all that 
bigger stuff.

#C: Reinstalling might not actually fix the problem, but only make the 
current memory problem go away... or maybe not even that.  The actual 
origin of the problem could be lurking in a lot places, e.g., with the 
drive (which see below), with a small bit of the RAM where the 
executable got 

Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-07 Thread m . roth
ken wrote:
 On Sun, Jan 06, 2013 at 06:23:20PM -0500, ken wrote:
 On 01/06/2013 05:18 PM fred smith wrote:
 On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote:
 On 01/06/2013 09:55 AM fred smith wrote:
 On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:
 Fred,

 Also running an up-to-date 5.8 but with just 2G of RAM,
 clock-applet consumes the following:

 PID USER PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 4133 me  15   0 29568 3748 2944 S  0.0  0.2 190:51.33 clock-applet
snip
 it's the same version and size as yours, but the md5sum differs. have
 you perhaps disabled prelink? (I don't call that I have ever done so)
 It's not obvious to me what other (legitimate) event would account for
 the difference in checksum.
snip
I've not been in this thread, but the above cmt *deeply* disturbs me. I'd
start by yum remove the package with the applet and reinstall... after
double checking what mirror it's getting the package from.

Yes, an infected repo is what's running through my mind, or a hijacked URL.

   mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-07 Thread m . roth
ken wrote:
 On Sun, Jan 06, 2013 at 06:23:20PM -0500, ken wrote:
 On 01/06/2013 05:18 PM fred smith wrote:
 On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote:
 On 01/06/2013 09:55 AM fred smith wrote:
 On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:
 Fred,

 Also running an up-to-date 5.8 but with just 2G of RAM,
 clock-applet consumes the following:

 PID USER PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 4133 me  15   0 29568 3748 2944 S  0.0  0.2 190:51.33 clock-applet
snip
 it's the same version and size as yours, but the md5sum differs. have
 you perhaps disabled prelink? (I don't call that I have ever done so)
 It's not obvious to me what other (legitimate) event would account for
 the difference in checksum.
snip
I've not been in this thread, but the above cmt *deeply* disturbs me. I'd
start by yum remove the package with the applet and reinstall... after
double checking what mirror it's getting the package from.

Yes, an infected repo is what's running through my mind, or a hijacked URL.

   mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-07 Thread Nicolas Thierry-Mieg
m.r...@5-cent.us wrote:
 ken wrote:
 On Sun, Jan 06, 2013 at 06:23:20PM -0500, ken wrote:
 On 01/06/2013 05:18 PM fred smith wrote:
 On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote:
 On 01/06/2013 09:55 AM fred smith wrote:
 On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:
 Fred,

 Also running an up-to-date 5.8 but with just 2G of RAM,
 clock-applet consumes the following:

 PID USER PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 4133 me  15   0 29568 3748 2944 S  0.0  0.2 190:51.33 clock-applet
 snip
 it's the same version and size as yours, but the md5sum differs. have
 you perhaps disabled prelink? (I don't call that I have ever done so)
 It's not obvious to me what other (legitimate) event would account for
 the difference in checksum.
 snip
 I've not been in this thread, but the above cmt *deeply* disturbs me. I'd
 start by yum remove the package with the applet and reinstall... after
 double checking what mirror it's getting the package from.

 Yes, an infected repo is what's running through my mind, or a hijacked URL.

highly unlikely IMO.
Remember: packages are signed. A bad guy would also need to have the 
centos key...

and I believe prelink does this sort of thing.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-07 Thread m . roth
Nicolas Thierry-Mieg wrote:
 m.r...@5-cent.us wrote:
 ken wrote:
 On Sun, Jan 06, 2013 at 06:23:20PM -0500, ken wrote:
 On 01/06/2013 05:18 PM fred smith wrote:
 On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote:
 On 01/06/2013 09:55 AM fred smith wrote:
 On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:

 Also running an up-to-date 5.8 but with just 2G of RAM,
 clock-applet consumes the following:

 PID USER PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 4133 me  15   0 29568 3748 2944 S  0.0  0.2 190:51.33
 clock-applet
 snip
 it's the same version and size as yours, but the md5sum differs.
 have you perhaps disabled prelink? (I don't call that I have ever done
 so) It's not obvious to me what other (legitimate) event would account
 for the difference in checksum.
 snip
 I've not been in this thread, but the above cmt *deeply* disturbs me.
 I'd  start by yum remove the package with the applet and reinstall...
after
 double checking what mirror it's getting the package from.

 Yes, an infected repo is what's running through my mind, or a hijacked
 URL.

 highly unlikely IMO.
 Remember: packages are signed. A bad guy would also need to have the
 centos key...

 and I believe prelink does this sort of thing.

Would change the md5sum of the package?

   mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-07 Thread Akemi Yagi
On Mon, Jan 7, 2013 at 8:10 AM,  m.r...@5-cent.us wrote:
 Nicolas Thierry-Mieg wrote:

 and I believe prelink does this sort of thing.

 Would change the md5sum of the package?

prelink does change the md5sum. One needs to unprelink (use the -u
flag) before comparing the hash value.

Akemi
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-07 Thread Gordon Messmer
On 01/07/2013 08:14 AM, Akemi Yagi wrote:
 prelink does change the md5sum. One needs to unprelink (use the -u
 flag) before comparing the hash value.

Indeed.  The prelink binary has --md5 and --sha flags to print the hash 
of the binary without prelink's data, and should be used in this case.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-07 Thread Robert Nichols
On 01/06/2013 06:32 PM, fred smith wrote:
 yes, it's on. there's a log in /var/log/prelink from just yesterday morning.

 wouldn't ya think that if prelink has modified it, that the rpm -V would
 have flagged a modified checksum? Or is prelink smart enuff to tweak
 the RPM database? I have no clue.

rpm is smart enough to undo the prelinking (to a temporary file) before 
verifying the checksum. IIRC, it also then re-prelinks the temp file and
verifies that the result matches the current file on disk.

-- 
Bob Nichols NOSPAM is really part of my email address.
 Do NOT delete it.

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-06 Thread ken
Fred,

Also running an up-to-date 5.8 but with just 2G of RAM, clock-applet 
consumes the following:

PID USER PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
4133 me  15   0 29568 3748 2944 S  0.0  0.2 190:51.33 clock-applet

My uptime at the moment is coming on 68 days.  Over time the %CPU field 
may flicker up to 0.3 or even 0.7, but the RES column and others are 
steady at the numbers you see.  I should add that all Preferences which 
we'd expect to consume more resources (e.g., display seconds, 12-hour 
time) are on.

Do you use evolution?

KDE, Gnome, or other WM?


On 01/04/2013 05:11 PM fred smith wrote:
 I've discovered recently that something on my Centos 5.8 box (up to date)
 is hogging a ton of RAM.

 so a little while ago I sat and watched top for a while. it showed
 (sorry, I didn't take screen shots or write this down, so the numbers
 are a bit rough) that out of 8 gigs of swap, around 2 1/2 was in use,
 and all the RAM (except for the little the kernel keeps for itself)
 was in use (it's got 4 gigs).

 this might not sound bad, but there's hardly ever anything big running
 on this box, it's just my home desktop machine used mostly for web
 browsing/music/email and similar.

 so, watching top run for a while I could eventually make out that
 something had 1.6g flashing in the RES column. slowing the refresh
 a little I saw that it was clock applet. so I killed the clock applet
 and restarted it, then clock applet showed 11m in the RES column,
 and the unused RAM was suddenly like a gig and 3/4, or so, and the
 swap used slowly started dropping while the free ram began being used up,
 as it normally should.

 as I continue to watch it run (10-15 mins later) I can see that clock
 applet is now showing 14m in the RES column, so it's still growing.

 Is anyone else seeing the clock applet hogging (tons of tiny leaks, I
 assume) RAM needlessly?

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-06 Thread fred smith
On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:
 Fred,
 
 Also running an up-to-date 5.8 but with just 2G of RAM, clock-applet 
 consumes the following:
 
 PID USER PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 4133 me  15   0 29568 3748 2944 S  0.0  0.2 190:51.33 clock-applet
 
 My uptime at the moment is coming on 68 days.  Over time the %CPU field 
 may flicker up to 0.3 or even 0.7, but the RES column and others are 
 steady at the numbers you see.  I should add that all Preferences which 
 we'd expect to consume more resources (e.g., display seconds, 12-hour 
 time) are on.
 
 Do you use evolution?

no, I have never found it to my liking.

 
 KDE, Gnome, or other WM?

gnome.

 
 
 On 01/04/2013 05:11 PM fred smith wrote:
  I've discovered recently that something on my Centos 5.8 box (up to date)
  is hogging a ton of RAM.
 
  so a little while ago I sat and watched top for a while. it showed
  (sorry, I didn't take screen shots or write this down, so the numbers
  are a bit rough) that out of 8 gigs of swap, around 2 1/2 was in use,
  and all the RAM (except for the little the kernel keeps for itself)
  was in use (it's got 4 gigs).
 
  this might not sound bad, but there's hardly ever anything big running
  on this box, it's just my home desktop machine used mostly for web
  browsing/music/email and similar.
 
  so, watching top run for a while I could eventually make out that
  something had 1.6g flashing in the RES column. slowing the refresh
  a little I saw that it was clock applet. so I killed the clock applet
  and restarted it, then clock applet showed 11m in the RES column,
  and the unused RAM was suddenly like a gig and 3/4, or so, and the
  swap used slowly started dropping while the free ram began being used up,
  as it normally should.
 
  as I continue to watch it run (10-15 mins later) I can see that clock
  applet is now showing 14m in the RES column, so it's still growing.
 
  Is anyone else seeing the clock applet hogging (tons of tiny leaks, I
  assume) RAM needlessly?
 
 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos

-- 
 Fred Smith -- fre...@fcshome.stoneham.ma.us -
The Lord detests the way of the wicked 
  but he loves those who pursue righteousness.
- Proverbs 15:9 (niv) -
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-06 Thread ken
On 01/06/2013 09:55 AM fred smith wrote:
 On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:
 Fred,

 Also running an up-to-date 5.8 but with just 2G of RAM, clock-applet
 consumes the following:

 PID USER PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 4133 me  15   0 29568 3748 2944 S  0.0  0.2 190:51.33 clock-applet

 My uptime at the moment is coming on 68 days.  Over time the %CPU field
 may flicker up to 0.3 or even 0.7, but the RES column and others are
 steady at the numbers you see.  I should add that all Preferences which
 we'd expect to consume more resources (e.g., display seconds, 12-hour
 time) are on.

 Do you use evolution?

 no, I have never found it to my liking.


 KDE, Gnome, or other WM?

 gnome.

I don't know what to tell you then because, like you, I use gnome but 
not evolution.  So our systems-- what of them which are directly related 
to clock-applet-- are much the same, yet you have a memory problem with 
clock-applet which I don't.

Here are some items to compare:

# rpm -q gnome-panel
gnome-panel-2.16.1-7.el5
# ll /usr/libexec/clock-applet
-rwxr-xr-x 1 root root 88048 May 24  2008 /usr/libexec/clock-applet
# md5sum /usr/libexec/clock-applet
9d21ca21a0e99ad26aa10e1cd5b42024  /usr/libexec/clock-applet




 On 01/04/2013 05:11 PM fred smith wrote:
 I've discovered recently that something on my Centos 5.8 box (up to date)
 is hogging a ton of RAM.

 so a little while ago I sat and watched top for a while. it showed
 (sorry, I didn't take screen shots or write this down, so the numbers
 are a bit rough) that out of 8 gigs of swap, around 2 1/2 was in use,
 and all the RAM (except for the little the kernel keeps for itself)
 was in use (it's got 4 gigs).

 this might not sound bad, but there's hardly ever anything big running
 on this box, it's just my home desktop machine used mostly for web
 browsing/music/email and similar.

 so, watching top run for a while I could eventually make out that
 something had 1.6g flashing in the RES column. slowing the refresh
 a little I saw that it was clock applet. so I killed the clock applet
 and restarted it, then clock applet showed 11m in the RES column,
 and the unused RAM was suddenly like a gig and 3/4, or so, and the
 swap used slowly started dropping while the free ram began being used up,
 as it normally should.

 as I continue to watch it run (10-15 mins later) I can see that clock
 applet is now showing 14m in the RES column, so it's still growing.

 Is anyone else seeing the clock applet hogging (tons of tiny leaks, I
 assume) RAM needlessly?

 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-06 Thread Rob Kampen

On 01/07/2013 11:18 AM, fred smith wrote:

On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote:

On 01/06/2013 09:55 AM fred smith wrote:

On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:

Fred,

Also running an up-to-date 5.8 but with just 2G of RAM, clock-applet
consumes the following:

PID USER PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
4133 me  15   0 29568 3748 2944 S  0.0  0.2 190:51.33 clock-applet

My uptime at the moment is coming on 68 days.  Over time the %CPU field
may flicker up to 0.3 or even 0.7, but the RES column and others are
steady at the numbers you see.  I should add that all Preferences which
we'd expect to consume more resources (e.g., display seconds, 12-hour
time) are on.

Do you use evolution?

no, I have never found it to my liking.


KDE, Gnome, or other WM?

gnome.

I don't know what to tell you then because, like you, I use gnome but
not evolution.  So our systems-- what of them which are directly related
to clock-applet-- are much the same, yet you have a memory problem with
clock-applet which I don't.

here's what top reports today (clock-applet has not been restarted since
the event mentioned in my original posting):

   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
11159 fredex16   0  263m 149m  10m S  0.3  3.8   1:36.87 clock-applet

in which I note it is now up to 149m.


Here are some items to compare:

# rpm -q gnome-panel
gnome-panel-2.16.1-7.el5
# ll /usr/libexec/clock-applet
-rwxr-xr-x 1 root root 88048 May 24  2008 /usr/libexec/clock-applet
# md5sum /usr/libexec/clock-applet
9d21ca21a0e99ad26aa10e1cd5b42024  /usr/libexec/clock-applet


# rpm -q gnome-panel
gnome-panel-2.16.1-7.el5
# ll /usr/libexec/clock-applet
-rwxr-xr-x 1 root root 88048 May 24  2008 /usr/libexec/clock-applet
# md5sum /usr/libexec/clock-applet
2bc9a73a5251d1b4747ec133839412b7  /usr/libexec/clock-applet
I checked on one of my CentOS 5.8 systems and the size and version 
match. The md5sum is different, probably due to prelink.
No way for me to check memory leak without opening a gnome desktop, 
which I will try later, once I work out how to access via another 
gateway server.

it's the same version and size as yours, but the md5sum differs. have
you perhaps disabled prelink? (I don't call that I have ever done so)
It's not obvious to me what other (legitimate) event would account for
the difference in checksum.

If I run:

rpm -V -v gnome-panel

it shows no differences at all, so I don't think the clock-applet has
been damaged or hacked. (but I wonder what it shows on your system, since
yours has a different md5sum.)

/usr/libexec/clock-applet






On 01/04/2013 05:11 PM fred smith wrote:

I've discovered recently that something on my Centos 5.8 box (up to date)
is hogging a ton of RAM.

so a little while ago I sat and watched top for a while. it showed
(sorry, I didn't take screen shots or write this down, so the numbers
are a bit rough) that out of 8 gigs of swap, around 2 1/2 was in use,
and all the RAM (except for the little the kernel keeps for itself)
was in use (it's got 4 gigs).

this might not sound bad, but there's hardly ever anything big running
on this box, it's just my home desktop machine used mostly for web
browsing/music/email and similar.

so, watching top run for a while I could eventually make out that
something had 1.6g flashing in the RES column. slowing the refresh
a little I saw that it was clock applet. so I killed the clock applet
and restarted it, then clock applet showed 11m in the RES column,
and the unused RAM was suddenly like a gig and 3/4, or so, and the
swap used slowly started dropping while the free ram began being used up,
as it normally should.

as I continue to watch it run (10-15 mins later) I can see that clock
applet is now showing 14m in the RES column, so it's still growing.

Is anyone else seeing the clock applet hogging (tons of tiny leaks, I
assume) RAM needlessly?


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-06 Thread ken
On 01/06/2013 05:18 PM fred smith wrote:
 On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote:
 On 01/06/2013 09:55 AM fred smith wrote:
 On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:
 Fred,

 Also running an up-to-date 5.8 but with just 2G of RAM, clock-applet
 consumes the following:

 PID USER PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 4133 me  15   0 29568 3748 2944 S  0.0  0.2 190:51.33 clock-applet

 My uptime at the moment is coming on 68 days.  Over time the %CPU field
 may flicker up to 0.3 or even 0.7, but the RES column and others are
 steady at the numbers you see.  I should add that all Preferences which
 we'd expect to consume more resources (e.g., display seconds, 12-hour
 time) are on.

 Do you use evolution?

 no, I have never found it to my liking.


 KDE, Gnome, or other WM?

 gnome.

 I don't know what to tell you then because, like you, I use gnome but
 not evolution.  So our systems-- what of them which are directly related
 to clock-applet-- are much the same, yet you have a memory problem with
 clock-applet which I don't.

 here's what top reports today (clock-applet has not been restarted since
 the event mentioned in my original posting):

PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 11159 fredex16   0  263m 149m  10m S  0.3  3.8   1:36.87 clock-applet

 in which I note it is now up to 149m.


 Here are some items to compare:

 # rpm -q gnome-panel
 gnome-panel-2.16.1-7.el5
 # ll /usr/libexec/clock-applet
 -rwxr-xr-x 1 root root 88048 May 24  2008 /usr/libexec/clock-applet
 # md5sum /usr/libexec/clock-applet
 9d21ca21a0e99ad26aa10e1cd5b42024  /usr/libexec/clock-applet

 # rpm -q gnome-panel
 gnome-panel-2.16.1-7.el5
 # ll /usr/libexec/clock-applet
 -rwxr-xr-x 1 root root 88048 May 24  2008 /usr/libexec/clock-applet
 # md5sum /usr/libexec/clock-applet
 2bc9a73a5251d1b4747ec133839412b7  /usr/libexec/clock-applet

 it's the same version and size as yours, but the md5sum differs. have
 you perhaps disabled prelink? (I don't call that I have ever done so)
 It's not obvious to me what other (legitimate) event would account for
 the difference in checksum.

Take a look in /etc/sysconfig/prelink.  At the top it should tell you if 
you've got prelink on.  You should also have a file called prelink in 
/etc/cron.daily/.

If none of that explains things, you might want to just reinstall 
gnome-panel and see if that fixes the memory problem.



 If I run:

   rpm -V -v gnome-panel

 it shows no differences at all, so I don't think the clock-applet has
 been damaged or hacked. (but I wonder what it shows on your system, since
 yours has a different md5sum.)

   /usr/libexec/clock-applet

Yeah, same here.

The clock applet would be a weird thing for somebody to hack.  But maybe 
you're seeing an early sign of a disk problem.  Bit rot or something 
like it could damage the executable.


 On 01/04/2013 05:11 PM fred smith wrote:
 I've discovered recently that something on my Centos 5.8 box (up to date)
 is hogging a ton of RAM.

 so a little while ago I sat and watched top for a while. it showed
 (sorry, I didn't take screen shots or write this down, so the numbers
 are a bit rough) that out of 8 gigs of swap, around 2 1/2 was in use,
 and all the RAM (except for the little the kernel keeps for itself)
 was in use (it's got 4 gigs).

 this might not sound bad, but there's hardly ever anything big running
 on this box, it's just my home desktop machine used mostly for web
 browsing/music/email and similar.

 so, watching top run for a while I could eventually make out that
 something had 1.6g flashing in the RES column. slowing the refresh
 a little I saw that it was clock applet. so I killed the clock applet
 and restarted it, then clock applet showed 11m in the RES column,
 and the unused RAM was suddenly like a gig and 3/4, or so, and the
 swap used slowly started dropping while the free ram began being used up,
 as it normally should.

 as I continue to watch it run (10-15 mins later) I can see that clock
 applet is now showing 14m in the RES column, so it's still growing.

 Is anyone else seeing the clock applet hogging (tons of tiny leaks, I
 assume) RAM needlessly?

 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos

 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] gigantic memory leak in Clock Applet...

2013-01-06 Thread fred smith
On Sun, Jan 06, 2013 at 06:23:20PM -0500, ken wrote:
 On 01/06/2013 05:18 PM fred smith wrote:
  On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote:
  On 01/06/2013 09:55 AM fred smith wrote:
  On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:
  Fred,
 
  Also running an up-to-date 5.8 but with just 2G of RAM, clock-applet
  consumes the following:
 
  PID USER PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
  4133 me  15   0 29568 3748 2944 S  0.0  0.2 190:51.33 clock-applet
 
  My uptime at the moment is coming on 68 days.  Over time the %CPU field
  may flicker up to 0.3 or even 0.7, but the RES column and others are
  steady at the numbers you see.  I should add that all Preferences which
  we'd expect to consume more resources (e.g., display seconds, 12-hour
  time) are on.
 
  Do you use evolution?
 
  no, I have never found it to my liking.
 
 
  KDE, Gnome, or other WM?
 
  gnome.
 
  I don't know what to tell you then because, like you, I use gnome but
  not evolution.  So our systems-- what of them which are directly related
  to clock-applet-- are much the same, yet you have a memory problem with
  clock-applet which I don't.
 
  here's what top reports today (clock-applet has not been restarted since
  the event mentioned in my original posting):
 
 PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
  11159 fredex16   0  263m 149m  10m S  0.3  3.8   1:36.87 clock-applet

it's now up to 156m. :(

 
  in which I note it is now up to 149m.
 
 
  Here are some items to compare:
 
  # rpm -q gnome-panel
  gnome-panel-2.16.1-7.el5
  # ll /usr/libexec/clock-applet
  -rwxr-xr-x 1 root root 88048 May 24  2008 /usr/libexec/clock-applet
  # md5sum /usr/libexec/clock-applet
  9d21ca21a0e99ad26aa10e1cd5b42024  /usr/libexec/clock-applet
 
  # rpm -q gnome-panel
  gnome-panel-2.16.1-7.el5
  # ll /usr/libexec/clock-applet
  -rwxr-xr-x 1 root root 88048 May 24  2008 /usr/libexec/clock-applet
  # md5sum /usr/libexec/clock-applet
  2bc9a73a5251d1b4747ec133839412b7  /usr/libexec/clock-applet
 
  it's the same version and size as yours, but the md5sum differs. have
  you perhaps disabled prelink? (I don't call that I have ever done so)
  It's not obvious to me what other (legitimate) event would account for
  the difference in checksum.
 
 Take a look in /etc/sysconfig/prelink.  At the top it should tell you if 
 you've got prelink on.  You should also have a file called prelink in 
 /etc/cron.daily/.

yes, it's on. there's a log in /var/log/prelink from just yesterday morning.

wouldn't ya think that if prelink has modified it, that the rpm -V would
have flagged a modified checksum? Or is prelink smart enuff to tweak
the RPM database? I have no clue.

 
 If none of that explains things, you might want to just reinstall 
 gnome-panel and see if that fixes the memory problem.

might try that, though it pains me to have to resort to the sort of 
fixes that Windows folks think are normal: power off, power on: reinstall:
reboot. Gah!
:)
 
 
 
  If I run:
 
  rpm -V -v gnome-panel
 
  it shows no differences at all, so I don't think the clock-applet has
  been damaged or hacked. (but I wonder what it shows on your system, since
  yours has a different md5sum.)
 
  /usr/libexec/clock-applet
 
 Yeah, same here.
 
 The clock applet would be a weird thing for somebody to hack.  But maybe 
 you're seeing an early sign of a disk problem.  Bit rot or something 
 like it could damage the executable.

I suppose it's POSSIBLE. I'm running two identical drives in a RAID-1
configuration, but as I understand it, RAID doesn't cover things like
invalid/incorrect reads from a drive, it merely provides redundancy in
case of total failure.

Thanks for the ideas, I'll post back to the list if anything interesting
turns up.

Fred
 
 
  On 01/04/2013 05:11 PM fred smith wrote:
  I've discovered recently that something on my Centos 5.8 box (up to 
  date)
  is hogging a ton of RAM.
 
  so a little while ago I sat and watched top for a while. it showed
  (sorry, I didn't take screen shots or write this down, so the numbers
  are a bit rough) that out of 8 gigs of swap, around 2 1/2 was in use,
  and all the RAM (except for the little the kernel keeps for itself)
  was in use (it's got 4 gigs).
 
  this might not sound bad, but there's hardly ever anything big running
  on this box, it's just my home desktop machine used mostly for web
  browsing/music/email and similar.
 
  so, watching top run for a while I could eventually make out that
  something had 1.6g flashing in the RES column. slowing the refresh
  a little I saw that it was clock applet. so I killed the clock applet
  and restarted it, then clock applet showed 11m in the RES column,
  and the unused RAM was suddenly like a gig and 3/4, or so, and the
  swap used slowly started dropping while the free ram began being used 
  up,
  as it normally should.
 
  as I continue to watch it run (10-15 mins later) I can see that clock
  

[CentOS] gigantic memory leak in Clock Applet...

2013-01-04 Thread fred smith
I've discovered recently that something on my Centos 5.8 box (up to date)
is hogging a ton of RAM.

so a little while ago I sat and watched top for a while. it showed
(sorry, I didn't take screen shots or write this down, so the numbers
are a bit rough) that out of 8 gigs of swap, around 2 1/2 was in use,
and all the RAM (except for the little the kernel keeps for itself)
was in use (it's got 4 gigs).

this might not sound bad, but there's hardly ever anything big running
on this box, it's just my home desktop machine used mostly for web
browsing/music/email and similar.

so, watching top run for a while I could eventually make out that 
something had 1.6g flashing in the RES column. slowing the refresh
a little I saw that it was clock applet. so I killed the clock applet
and restarted it, then clock applet showed 11m in the RES column,
and the unused RAM was suddenly like a gig and 3/4, or so, and the
swap used slowly started dropping while the free ram began being used up,
as it normally should.

as I continue to watch it run (10-15 mins later) I can see that clock
applet is now showing 14m in the RES column, so it's still growing.

Is anyone else seeing the clock applet hogging (tons of tiny leaks, I
assume) RAM needlessly?

-- 
 Fred Smith -- fre...@fcshome.stoneham.ma.us -
   I can do all things through Christ 
  who strengthens me.
-- Philippians 4:13 ---
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos