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/627...
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming blog:
http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)