GNOME Bugzilla – Bug 745695
pango_layout_set_markup Memory Leak
Last modified: 2015-03-23 22:40:26 UTC
Hello, When I set a Pango layout with markup (in this case superscript or subscript), I get a memory leak after a call to pango_layout_get_extents. Nothing leaks if I supply plain text or don't call pango_layout_get_extents. It's pretty bad if I run my program for hours (it eventually crashes). I'm using Pango 1.36.8 on Windows 7. Thanks! Geoffrey #include <gtk/gtk.h> int main( int argc, char *argv[] ) { cairo_surface_t *surface = cairo_image_surface_create( CAIRO_FORMAT_RGB24, 640, 480 ); PangoLayout *layout = pango_cairo_create_layout( cairo_create(surface) ); while( 1 ) { // pango_layout_set_markup( layout, "Hello!", -1 ); // No leak. pango_layout_set_markup( layout, "Hello<sup>2</sup>", -1 ); // Leak. PangoRectangle ink_rect, logical_rect; pango_layout_get_extents( layout, &ink_rect, &logical_rect ); } return 0; }
How do you know it's leaking? That it crashes after hours? I can't reproduce using valgrind on Linux.
(In reply to Behdad Esfahbod from comment #1) > How do you know it's leaking? That it crashes after hours? I can't > reproduce using valgrind on Linux. Hi, I ran it under Windows and printed the process heap size inside the loop. The heap grew pretty rapidly with the markup and didn't grow at all without the markup. Maybe it's Windows specific? Geoffrey
Hello Again, I retried the experiment on a clean (non-development) computer running Windows 8. When I instrument the loop, here's what I get: Without superscript: 4113 entries 1843666 bytes 4113 entries 1843666 bytes 4113 entries 1843666 bytes 4113 entries 1843666 bytes 4113 entries 1843666 bytes ... 4113 entries 1843666 bytes With superscript: 4134 entries 2010709 bytes 4143 entries 2098959 bytes 4143 entries 2186959 bytes 4143 entries 2274959 bytes 4143 entries 2362959 bytes 4143 entries 2450959 bytes 4143 entries 2538959 bytes 4143 entries 2626959 bytes 4143 entries 2714959 bytes 4143 entries 2802959 bytes 4143 entries 2890959 bytes 4143 entries 2978959 bytes 4143 entries 3066959 bytes 4143 entries 3154959 bytes 4143 entries 3242959 bytes 4143 entries 3330959 bytes 4143 entries 3418959 bytes 4143 entries 3506959 bytes 4143 entries 3594959 bytes ... 4143 entries 16178959 bytes I'm printing out the number of heap entries and the total bytes in the main process heap every 1000 iterations. Without the superscript the heap counts are solid. With the superscript the number of heap entries is constant, but the number of bytes is growing. It looks like you're not leaking actual buffers, but accidentally growing some buffer without bound. If I let it run overnight I ultimately get the "GLib: gmem.c:168" can't allocate enormous buffer error. I hope this is helpful. Geoffrey
Hello Behdad, I had time to profile the test program a little more. I'm seeing that the memory is growing by exactly 88 bytes each iteration, independent of the text I provide. I hope this helps. Geoffrey
Thanks Geoffrey. I still cannot reproduce this. Would be great to run using a tool that would show where the allocation is coming from...
Hello Behdad, I tracked it down to a function call. Here's the stack trace where it's crashing (running out of memory): glib-2.0.dll!g_logv Line 1039 C glib-2.0.dll!g_log Line 1079 C glib-2.0.dll!g_realloc Line 168 C gobject-2.0.dll!g_object_weak_ref Line 2668 C gobject-2.0.dll!g_object_add_weak_pointer Line 2749 C pangocairo-1.0.dll!_pango_cairo_win32_font_new Line 256 C pangocairo-1.0.dll!pango_cairo_win32_font_map_find_font Line 104 C pangowin32-1.0.dll!pango_win32_font_map_load_font Line 961 C pangowin32-1.0.dll!pango_win32_font_map_fontset_add_fonts Line 704 C pangowin32-1.0.dll!pango_win32_font_map_load_fontset Line 1703 C pango-1.0.dll!itemize_state_update_for_new_run Line 1436 C pango-1.0.dll!itemize_state_process_run Line 1475 C pango-1.0.dll!pango_itemize_with_base_dir Line 1612 C pango-1.0.dll!pango_layout_check_lines Line 4008 C pango-1.0.dll!pango_layout_get_extents_internal Line 2589 C pango-1.0.dll!pango_layout_get_extents Line 2782 C TestGTK.exe!main Line 107 C++ Apparently, it is the Win32 functionality. _pango_cairo_win32_font_new is repetitively calling g_object_add_weak_pointer which is indirectly calling g_realloc and growing the weak pointer reference stack without bounds (88 bytes at a time). I'm not sure if I can track down the problem any further than that. I hope this is helpful! Geoffrey
Thanks Geoffrey. That explains why I can't reproduce this on Linux. Matthias recently committed a win32 weak-ref-related fix for bug 738868. Can you check if this is the same issue?
Hello Behdad, Sorry for the confusion. I applied the patch and the problem went away. When do you thing you'll have a new release? Thanks! Geoffrey
That's great. I think Matthias will make a release in a few weeks time, when the next GNOME release is scheduled. *** This bug has been marked as a duplicate of bug 738868 ***