GNOME Bugzilla – Bug 149313
Leak in libwnck or wnck-applet
Last modified: 2005-05-29 14:47:55 UTC
Hi, The memory usage of the wnck-applet increases during a session of several days: start: VIRT 20572, RES: 12M SHR: 16M some days later: VIRT 91116, RES: 47M SHR: 16M I don't know, whether this is a bug in the wnck-pager or the libwnck. gnome-panel: 2.6.2 libwnck: 2.6.2 There is an similar bug filed over a year ago (#111555). I tried to reproduce the memory leak with the mentioned small program in this bug report, but with no success. So I decided to create a new bug, because it could be another problem. regards, Christian
Here's what valgrind reports from a short run with tasklist and workspace switcher: ==22918== 176 bytes in 1 blocks are definitely lost in loss record 80 of 162 ==22918== at 0x3414FC25: calloc (vg_replace_malloc.c:176) ==22918== by 0x34984D03: g_malloc0 (gmem.c:153) ==22918== by 0x3490F4F3: g_type_create_instance (gtype.c:1575) ==22918== by 0x348F8983: g_object_constructor (gobject.c:1044) ==22918== by 0x348F7DB5: g_object_newv (gobject.c:941) ==22918== by 0x348F8866: g_object_new_valist (gobject.c:984) ==22918== by 0x348F8959: g_object_new (gobject.c:822) ==22918== by 0x3445F682: gtk_menu_new (gtkmenu.c:1104) ==22918== by 0x34173922: wnck_task_popup_menu (tasklist.c:1905) ==22918== by 0x34173DCF: wnck_task_button_press_event (tasklist.c:2341) ==22918== by 0x3445B978: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:82) ==22918== by 0x348F4FD4: g_closure_invoke (gclosure.c:437) ==22918== by 0x34908649: signal_emit_unlocked_R (gsignal.c:2435) ==22918== by 0x3490A15F: g_signal_emit_valist (gsignal.c:2204) ==22918== by 0x3490A71A: g_signal_emit (gsignal.c:2238) ==22918== by 0x34532979: gtk_widget_event_internal (gtkwidget.c:3563) ==22918== by 0x34459A36: gtk_propagate_event (gtkmain.c:2344) ==22918== by 0x34459D25: gtk_main_do_event (gtkmain.c:1582) ==22918== by 0x3461E561: gdk_event_dispatch (gdkevents-x11.c:2158) ==22918== by 0x3497F0AB: g_main_context_dispatch (gmain.c:1942) and: ==22918== 200 bytes in 1 blocks are definitely lost in loss record 86 of 162 ==22918== at 0x3414F2A8: malloc (vg_replace_malloc.c:131) ==22918== by 0x34931618: my_malloc (vg_libpthread.c:359) ==22918== by 0x349349C6: get_or_allocate_specifics_ptr (vg_libpthread.c:1729) ==22918== by 0x34934B4E: pthread_key_create (vg_libpthread.c:1766) ==22918== by 0x3492A713: g_private_new_posix_impl (gthread-posix.c:255) ==22918== by 0x349972C6: g_thread_init_glib (gthread.c:157) ==22918== by 0x3492B26C: g_thread_init (gthread-impl.c:377) ==22918== by 0x342FA671: bonobo_activation_pre_args_parse (gnome-init.c:117) ==22918== by 0x342F6C91: gnome_program_preinit (gnome-program.c:1324) ==22918== by 0x342F7762: gnome_program_init_common (gnome-program.c:1863) ==22918== by 0x342F7AA5: gnome_program_init (gnome-program.c:1683) ==22918== by 0x804E235: main (wncklet.c:77) The latter looks to be a problem deeper in the stack...
Hi Kjartan, can you explain how I can run the workspace switcher applet in valgrind? This was my first idea, too, but I don't know how I can run an applet in valgrind. Thx.
run /usr/libexec/wnck_applet in valgrind, then add workspace-switcher and tasklist after the first has stopped loading
I just see one unrelated leak here now. I do see a load of warnings when running things from the command line though. This is 2.7.9x/2.8.0. This is spewed all over the place: (wnck-applet:15781): Wnck-CRITICAL **: file window.c: line 1270 (wnck_window_get_state): assertion `WNCK_IS_WINDOW (window)' failed This is printed a couple of times (wnck-applet:15781): Wnck-WARNING **: Unhandled action type (nil) And this is printed on startup: (wnck-applet:15781): GConf-CRITICAL **: file gconf-client.c: line 547 (gconf_client_add_dir): assertion `gconf_valid_key (dirname, NULL)' failed
The two wnck warnings fixed on HEAD: 2004-09-21 Mark McLoughlin <mark@skynet.ie> Fix some runtime warning spew reported in bug #149313 * libwnck/tasklist.c: (wnck_task_get_demands_attention): impl. handling task groups as well as individual tasks. (wnck_task_update_visible_state), (wnck_task_create_widgets): use get_demands_attention() * libwnck/window.[ch]: (update_actions): handle the minimize and fullscreen actions.
Okay, I can't reproduce any leaks now with 2.8.0. Closing.
Sorry, but I have to re-open this bug, because the problem is not gone with 2.8.0: After start of wnck-applet: VIRT 18880 RES 11M after a week: VIRT 82904 RES 40M
Christian: can you tell us if you have the following applets in one of your panels: + window list + window selector + workspace switcher + show desktop button What would be great, is that you try to determine which applet is causing the leak.
I've the following wnck applets in my 2 panels: - window list (in the bottom panel) - workspace switcher (in the top panel) .
Way to make the wncklet leak a lot of memory really fast: Add a "window list" to your panel then go into the properties and adjust the "minimum size" up and down so that the list grows longer and shorter. Growing it to fill the length of the panel then back about twice results in the wncklet using an extra meg. Repeat.
Ryan: it doesn't work here... Memory grows at the beginning (probably because we load the preferences window), but that's all.
I found and fixed one leak today that could explain this. Could people test cvs HEAD to see if this still happens for them?
I've measured the memory consumption of the wnck-applet again in the last week: I've been using the gnome 2.10.1. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND ------------------------------------------------------------------------ 1 hour 6339 user1 16 0 19716 9576 7740 S 0.0 1.9 0:00.70 wnck-applet 10 hours 6339 user1 16 0 19996 9992 7884 S 0.0 1.9 0:07.58 wnck-applet 24 hours 6339 user1 16 0 22936 10M 8136 S 0.0 2.1 0:54.10 wnck-applet 35 hours 6339 user1 15 0 23152 11M 8220 S 0.0 2.2 1:28.20 wnck-applet 7 days 6339 user1 16 0 23876 9.8M 6408 S 0.0 2.0 2:51.15 wnck-applet It seems, that most of the memory leaks I originally reported are gone. The remaining slightly increase between 35 hours and 7 days could be a result of many open windows or something like that. From my point of view this bug is solved, because there is no more critical memory leak any more. What is the opinion of the maintainers about closing this bug?
Thanks for following up. Let's close it; the info you provide now isn't enough to know even whether there's a leak, let alone where it might be. (Although there was a really small leak that was fixed in the last few weeks...) If we get more detailed information (e.g. a valgrind report) then we can open up separate future bugs. :-)