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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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:
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
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
37 matches
Mail list logo