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#) -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
