pango+cairo hello world leaks

Question

I have problems with leaks in the pangocairo hello world example.

#include <cairo.h>
#include <pango/pangocairo.h>

int main(int argc, char *argv[])
    {
//  0
    cairo_surface_t* surface=cairo_image_surface_create (CAIRO_FORMAT_ARGB32, 240, 80);
//  1
    cairo_t* cr=cairo_create(surface);

//  2
    PangoFontDescription* font_description=pango_font_description_new();
    pango_font_description_set_family(font_description,"serif");
    pango_font_description_set_weight(font_description,PANGO_WEIGHT_BOLD);
    pango_font_description_set_absolute_size(font_description,32*PANGO_SCALE);

//  3
    PangoLayout* layout=pango_cairo_create_layout(cr);

    pango_layout_set_font_description(layout,font_description);
    pango_layout_set_text(layout,"Hello, world",-1);
    cairo_set_source_rgb (cr, 0.0, 0.0, 1.0);
    cairo_move_to (cr, 10.0, 50.0);
    pango_cairo_show_layout(cr,layout);

//  3
    g_object_unref(layout);

//  2
    pango_font_description_free(font_description);

//  1
    cairo_destroy (cr);

    cairo_surface_write_to_png (surface, "hello.png");

//  0
    cairo_surface_destroy (surface);
    return 0;
    }

Valgrind outputs

==5178==    definitely lost: 7,936 bytes in 28 blocks
==5178==    indirectly lost: 8,510 bytes in 374 blocks
==5178==      possibly lost: 1,514 bytes in 21 blocks
==5178==    still reachable: 567,835 bytes in 5,069 block

And complains about libfontconfig, and glib. Are there any missing cleanup above? If not should I care about it (post a bug report), or is it the lazy free policy of the GNOME project that shows up again?

Why is this a problem? Is any of this a "real" memory leak? – Uli Schlachter Aug 17 '19 at 19:05 — Uli Schlachter, Aug 17 '19 at 19:05

score 2 · Answer 1 · answered Aug 17 '19 at 19:07

2

I can get this from

==8376==    definitely lost: 3,840 bytes in 12 blocks
==8376==    indirectly lost: 7,822 bytes in 339 blocks
==8376==      possibly lost: 1,514 bytes in 21 blocks
==8376==    still reachable: 573,848 bytes in 4,977 blocks

to

==8394==    definitely lost: 0 bytes in 0 blocks
==8394==    indirectly lost: 0 bytes in 0 blocks
==8394==      possibly lost: 1,514 bytes in 21 blocks
==8394==    still reachable: 60,064 bytes in 368 blocks

via adding

    pango_cairo_font_map_set_default(NULL);
    cairo_debug_reset_static_data();
    FcFini();

at the end of the file. Note that FcFini() needs an extra #include <fontconfig/fontconfig.h> and linking against fontconfig.

From a quick look, the remaining complaints from valgrind are from GLib's type system getting set up. As far as I know, there is not much one can do to get rid of those false-positives.

answered Aug 17 '19 at 19:07

Uli Schlachter

9,337
1
23
39

1

To get rid of the GLib false positives, you can pass `--suppressions=/usr/share/glib-2.0/valgrind/glib.supp` to valgrind. – Philip Withnall Aug 19 '19 at 08:46
That gets rid of about 12 KiB of "still reachable", so it helps a bit, but also not all that much. Largest remaining leak is still from some constructor function in GLib (called by `_dl_init`, so must occur when the library is loaded). – Uli Schlachter Aug 20 '19 at 15:31
Thanks for checking. Please [file a bug against GLib](https://gitlab.gnome.org/GNOME/glib/issues/new) so we can update the suppressions file. – Philip Withnall Aug 21 '19 at 07:06

pango+cairo hello world leaks

1 Answers1