clock-applet memory leak

[Richard W.M. Jones]

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#6271

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