GNOME Bugzilla – Bug 351057
Leak in clearlooks_style.c
Last modified: 2006-08-13 19:21:15 UTC
Found this when running gnome-system-monitor in valgrind: ==9173== 36,300 (3,120 direct, 33,180 indirect) bytes in 65 blocks are definitely lost in loss record 6,686 of 6,782 ==9173== at 0x40053D0: malloc (vg_replace_malloc.c:149) ==9173== by 0xABD438: cairo_create (cairo.c:187) ==9173== by 0x9A1633: gdk_cairo_create (gdkcairo.c:46) ==9173== by 0x46E045F: ge_gdk_drawable_to_cairo (cairo-support.c:231) ==9173== by 0x46D50BD: clearlooks_style_draw_arrow (clearlooks_style.c:1154) ==9173== by 0x66D7B07: gtk_paint_arrow (gtkstyle.c:5756) ==9173== by 0x658DB50: gtk_arrow_expose (gtkarrow.c:237) ==9173== by 0x666788F: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:83)
This may be some sort of cairo leak, because clearlooks does - cairo_t *cr = ge_gdk_drawable_to_cairo (window, area); ..... cairo_destroy (cr); There is a single cairo reference, and a single cairo destroy, and nothing directly in the clearlooks draw arrow stack is keeping an extra reference so clearlooks is doing all it is supposed to do. Unless an error happened during drawing so that the destroy was never reached, which would be a completely different error, I don't see how this is an engine leak.
Hmm? It clearly returns early with this check and does not destroy the stuff allocated with ge_gdk_drawable_to_cairo()? if (arrow_type == (GtkArrowType)4)//NONE - new in GTK 2.10 { cairo_destroy (cr); return; } You could probably check arrow_type before allocating stuff too and not have to go through that at all when the test is true.
btw, the cairo_destroy() there was the one I added.
Aha. You are right. I somehow looked right past that return. It shouldn't be creating the cairo handle first anyway, because a failed sanitized size or invalid args would cause it to skip out without freeing as well. My bad. Fixed.