GNOME Bugzilla – Bug 151218
gnome-cups-icon has memory leak
Last modified: 2008-01-29 13:10:20 UTC
Built from CVS, problem also present in latest debian packages. Also built libgnomecups from CVS. libcups is debian libcupsys2-gnutls10 version 1.1.20final+rc1-5 gnome-cups-icon always leaks memory at about 134k a minute. Output from "cat /proc/<pid>/status | grep VmSize" at 1 minutes intervals: VmSize: 34480 kB VmSize: 34612 kB VmSize: 34748 kB VmSize: 34884 kB VmSize: 35012 kB VmSize: 35152 kB VmSize: 35288 kB VmSize: 35416 kB VmSize: 35556 kB VmSize: 35692 kB That makes about 64 megs of memory over the course of an 8 hour working day, so this is a serious problem.
could you try running this under valgrind to give us an idea about what the leak is, please?
Created attachment 31560 [details] Valgrind output from attempt to run gnome-cups-icon gnome-cups-icon terminates when launched in valgrind, rather than staying running indefitely as it normally would. The attached was generated using 'valgrind --leak-check=yes --trace-children=yes --tool=memcheck' Guess this probably won't be much use.
Try adding --alignment=8
Created attachment 31564 [details] valgrind output 'valgrind --alignment=8 --leak-check=yes --trace-children=yes --tool=memcheck' This time, it doesn't terminate (at least, it didn't in the time it took to watch the second half of Day of the Dead). Can't see anything too informative in the output though :-(
The actual leaks there are trivial, but lots of memory is in use at then end. Please try adding --show-reachable=yes and whatever option increased the length of the stack trace. The result might be big, :-/ Actually please try two runs of different length. (I am hoping that "diff" will help us see what is going on.)
Created attachment 31633 [details] valgrind output valgrind --alignment=8 --leak-check=yes --trace-children=yes --tool=memcheck --show-reachable=yes
Created attachment 31634 [details] more valgrind output Same commandline as previous, run for different length of time.
The hash functions are interesting, but we really need deeper stack traces in order to tell. Please add "--num-callers=20" and let the program run for quite a while, say half an hour. jody: do you observe the problem in your setup?
Created attachment 31654 [details] valgrind output valgrind --tool=memcheck --alignment=8 --leak-check=yes --trace-children=yes --show-reachable=yes --num-callers=20 Ran for 30 minutes and then ctrl-c.
This looks like the problem: ==29178== 1559520 bytes in 760 blocks are still reachable in loss record 153 of 154 ==29178== at 0x3C021C03: calloc (vg_replace_malloc.c:141) ==29178== by 0x3C8B24F0: cupsLangGet (in /usr/lib/libcups.so.2) ==29178== by 0x3C89FFA5: gnome_cups_request_new (gnome-cups-request.c:390) ==29178== by 0x3C8A00D0: gnome_cups_request_new_for_printer (gnome-cups-request.c:419) ==29178== by 0x3C89A3B9: update_attributes (gnome-cups-printer.c:296) ==29178== by 0x3C89AA07: update_printers (gnome-cups-printer.c:534) ==29178== by 0x3C89AAD4: update_printers_timeout (gnome-cups-printer.c:563) ==29178== by 0x3C9453AB: (within /usr/lib/libglib-2.0.so.0.400.6) ==29178== by 0x3C942931: (within /usr/lib/libglib-2.0.so.0.400.6) ==29178== by 0x3C943A27: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.400.6) ==29178== by 0x3C943D5F: (within /usr/lib/libglib-2.0.so.0.400.6) ==29178== by 0x3C9443A2: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.400.6) ==29178== by 0x3C3B1212: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.400.9) ==29178== by 0x804C728: main (gnome-cups-icon.c:145)
Looks like gnome_cups_request_new needs to call cupsLangFree(language); at the end.
Seems reasonable. The version of cups I checked seemed to have reference counted the language. I'm doubting this was the leak the original reporter was seeing. We can reopen if they still see problems
Moving all gnome-cups-manager bugs to new product. Filter on Kjartan's spring cleaning.