I reported the large memory leak in clock-applet:
https://bugzilla.redhat.com/show_bug.cgi?id=952763
(TLDR: clock-applet grows by 1GB/day when reporting weather)
Since clock-applet is a default install on every Fedora, I thought this would be widely reported---it essentially makes the system unusable within a day or two if you run into this problem---but that doesn't seem to be the case. I guess people don't see it because nobody reconfigures clock-applet.
Anyway, I am looking for a way to debug this: I tried attaching GDB to the running process but the results are unreliable (see BZ). I couldn't figure out how to run valgrind on the executable: it has to be run in the context of the Gnome panel, so how do I tell it to run 'valgrind /usr/libexec/clock-applet', and how do I get access to the results? Is there another way?
On Mon, Apr 22, 2013 at 12:55:00PM -0400, Przemek Klosowski wrote:
I reported the large memory leak in clock-applet:
https://bugzilla.redhat.com/show_bug.cgi?id=952763
(TLDR: clock-applet grows by 1GB/day when reporting weather)
Since clock-applet is a default install on every Fedora, I thought this would be widely reported---it essentially makes the system unusable within a day or two if you run into this problem---but that doesn't seem to be the case. I guess people don't see it because nobody reconfigures clock-applet.
Anyway, I am looking for a way to debug this: I tried attaching GDB to the running process but the results are unreliable (see BZ). I couldn't figure out how to run valgrind on the executable: it has to be run in the context of the Gnome panel, so how do I tell it to run 'valgrind /usr/libexec/clock-applet', and how do I get access to the results? Is there another way?
One trick I've used in the past is to core dump the process (set 'ulimit -c unlimited' before startx, then kill -SEGV $clockpid), and parse it with some simple command line tools.
sort < core | uniq -c | sort -nr
Example: https://bugzilla.redhat.com/show_bug.cgi?id=890039#c2
This will tell you if some obvious string is being leaked. Unfortunately it's not useful for any other type of leak. But you never know, and it only takes a few minutes to do this analysis.
Rich.
PS. If you can't coredump the process, you can probably read /proc/$pid/mem instead, but note that simple 'cat' won't work: http://unix.stackexchange.com/questions/6267/how-to-unswap-my-desktop/6271#6...
On 04/22/2013 03:06 PM, Richard W.M. Jones wrote:
One trick I've used in the past is to core dump the process (set 'ulimit -c unlimited' before startx, then kill -SEGV $clockpid), and parse it with some simple command line tools.
You can use GDB for that: gdb -p $clockpid followed by
(gdb) gcore /tmp/clock-applet-core Saved corefile /tmp/clock-applet-core
sort < core | uniq -c | sort -nr
Nice idiom---I also discovered it some time ago and I find myself using it regularly.
On Mon, 22 Apr 2013 12:55:00 -0400 Przemek Klosowski przemek.klosowski@nist.gov wrote:
I reported the large memory leak in clock-applet:
https://bugzilla.redhat.com/show_bug.cgi?id=952763
(TLDR: clock-applet grows by 1GB/day when reporting weather)
Ouch. Until this is fixed, I duct-taped around by adding this line to cron:
*/5 * * * * /home/conrad/kill_clock_applet_leak.sh
Script:
#!/bin/bash
memused="`ps auxwww|grep clock-ap[p]let | awk '{ print $6 }'`"
if [[ $memused -gt 250000 ]]; then memhuman="$((memused/1024))" echo "Clock-applet using $memhuman MB, killing panel" pkill gnome-panel fi
It's ugly and dumb, but should prevent run-away stupidity... (kills at 250MB RSS).
Conrad
On 04/23/2013 12:25 AM, Conrad Meyer wrote:
On Mon, 22 Apr 2013 12:55:00 -0400 Przemek Klosowski przemek.klosowski@nist.gov wrote:
I reported the large memory leak in clock-applet:
https://bugzilla.redhat.com/show_bug.cgi?id=952763
(TLDR: clock-applet grows by 1GB/day when reporting weather)
Ouch. Until this is fixed, I duct-taped around by adding this line to cron:
*/5 * * * * /home/conrad/kill_clock_applet_leak.sh
Script:
#!/bin/bash
memused="`ps auxwww|grep clock-ap[p]let | awk '{ print $6 }'`"
if [[ $memused -gt 250000 ]]; then memhuman="$((memused/1024))" echo "Clock-applet using $memhuman MB, killing panel" pkill gnome-panel fi
It's ugly and dumb, but should prevent run-away stupidity... (kills at 250MB RSS).
I played those games too---I found a direct way of getting memory use of a given process from ps: memMB=$[`ps -o rss= -C clock-applet`/1024]
BTW, why did you use 'clock-ap[p]let'?
FWIW, here's a snippet that I used to collect data on memory used by the app vs. time (minutes):
printf -v ti '%(%s)T' -1; while sleep 60 ; do printf -v t '%(%s)T' -1; echo $[($t-$ti)/60] `ps -o rss= -C clock-applet` ; done
On Tue, Apr 23, 2013 at 10:30:14AM -0400, Przemek Klosowski wrote:
On 04/23/2013 12:25 AM, Conrad Meyer wrote:
memused="`ps auxwww|grep clock-ap[p]let | awk '{ print $6 }'`"
[...]
BTW, why did you use 'clock-ap[p]let'?
So that the grep command itself would not be matched by the grep.
Rich.
On Mon, Apr 22, 2013 at 09:25:48PM -0700, Conrad Meyer wrote:
memused="`ps auxwww|grep clock-ap[p]let | awk '{ print $6 }'`"
memused="$(ps -ho rss `pidof clock-applet`)"
This is simplier and more clear.
On Mon, Apr 22, 2013 at 6:55 PM, Przemek Klosowski przemek.klosowski@nist.gov wrote:
Since clock-applet is a default install on every Fedora, I thought this would be widely reported
While it is installed on every (default desktop spin) Fedora system, it is only used by the (non-default) GNOME fallback mode, which is likely why it hasn't been reported as much as you assumed. It is also unmaintained upstream and will no longer be included in Fedora 19.
On 04/23/2013 07:40 PM, Florian Müllner wrote:
On Mon, Apr 22, 2013 at 6:55 PM, Przemek Klosowski przemek.klosowski@nist.gov wrote:
Since clock-applet is a default install on every Fedora, I thought this would be widely reported
While it is installed on every (default desktop spin) Fedora system, it is only used by the (non-default) GNOME fallback mode, which is likely why it hasn't been reported as much as you assumed. It is also unmaintained upstream and will no longer be included in Fedora 19.
Oh, that's funny because my Gnome uses fallback mode because of problems with Intel graphics drivers, which is the other critical bug I have open: https://bugzilla.redhat.com/show_bug.cgi?id=922224 which essentially crashes everything that uses OpenGL (all 3D and some 2D drawing applications).
Just my luck I guess. Time for a new hardware.
On Wed, 2013-04-24 at 11:22 -0400, Przemek Klosowski wrote:
On 04/23/2013 07:40 PM, Florian Müllner wrote:
On Mon, Apr 22, 2013 at 6:55 PM, Przemek Klosowski przemek.klosowski@nist.gov wrote:
Since clock-applet is a default install on every Fedora, I thought this would be widely reported
While it is installed on every (default desktop spin) Fedora system, it is only used by the (non-default) GNOME fallback mode, which is likely why it hasn't been reported as much as you assumed. It is also unmaintained upstream and will no longer be included in Fedora 19.
Oh, that's funny because my Gnome uses fallback mode because of problems with Intel graphics drivers, which is the other critical bug I have open: https://bugzilla.redhat.com/show_bug.cgi?id=922224 which essentially crashes everything that uses OpenGL (all 3D and some 2D drawing applications).
Just my luck I guess. Time for a new hardware.
You could try F19. Wasn't there some chatter that that 'all 3D stuff crashes on old Intel hardware' had got fixed in F19? IMBW, I guess.
On 05/02/2013 05:43 PM, Adam Williamson wrote:
On Wed, 2013-04-24 at 11:22 -0400, Przemek Klosowski wrote:
On 04/23/2013 07:40 PM, Florian Müllner wrote:
On Mon, Apr 22, 2013 at 6:55 PM, Przemek Klosowski przemek.klosowski@nist.gov wrote:
Since clock-applet is a default install on every Fedora, I thought this would be widely reported
While it is installed on every (default desktop spin) Fedora system, it is only used by the (non-default) GNOME fallback mode, which is likely why it hasn't been reported as much as you assumed. It is also unmaintained upstream and will no longer be included in Fedora 19.
Oh, that's funny because my Gnome uses fallback mode because of problems with Intel graphics drivers, which is the other critical bug I have open: https://bugzilla.redhat.com/show_bug.cgi?id=922224 which essentially crashes everything that uses OpenGL (all 3D and some 2D drawing applications).
Just my luck I guess. Time for a new hardware.
You could try F19. Wasn't there some chatter that that 'all 3D stuff crashes on old Intel hardware' had got fixed in F19? IMBW, I guess.
I did--I submitted my report to the Intel graphics test page. It seems that this particular problem has been fixed although some 3D apps still crash, in a different place.
-
Adam Williamson -
Alexey I. Froloff -
Conrad Meyer -
Florian Müllner -
Przemek Klosowski -
Richard W.M. Jones