411030 - GTK moz_drawingarea leak

Status: RESOLVED INCOMPLETE

(Core :: Widget: Gtk, defect, P3)

Description

[Robert Sayre]

Will attach a stack.

Comment 1

[Robert Sayre]

Attachment: valgrind stack

Comment 2

[Robert Sayre]

Requesting blocking because this leak appears to grow unbounded as pages are visited.

Comment 3

[Michael Ventnor]

Are there any specific conditions which trigger this leak?

Comment 4

[Robert Sayre]

It happens every time I run the browser on Ubuntu 7.10.

Comment 5

[Michael Ventnor]

This one has me stumped... The refcount of the drawing area is always set to 0 when the nsWindow is destroyed and there are no cases where the two booleans at the top of Destroy() are in the wrong state. Is there any other info or hints you could give me?

Comment 6

[Mike Schroepfer]

Moving to blocking list based on comment 2

Comment 7

[Robert Sayre]

I can only get this to happen x64 Ubuntu 7.10. On 32-bit Ubuntu, it works fine.

Comment 8

[Matthew Gregan [:kinetik]]

Unfortunately I can't reproduce this locally.  Based on comment #7, I did a fresh install of 7.10 x64 in a VM but don't see the leak with a trunk debug build.  Just in case it matters, the steps I tested were:

1. Run valgrind --leak-check=full --num-callers=32 firefox-bin
2. Open a few windows and let the default page load in each
3. Open a few tabs in each window, don't load any additional pages
4. Close each of the windows until firefox exits

I see the usual suspects leaking (e.g. pango/fontconfig), but no moz_drawingarea leaks.  The install is stock with none of the pending updates applied except a few (pango, cairo, no gtk or glib) dragged in automatically by apt-get build-dep firefox-3.0 and apt-get install libdbus-glib-1-dev to set up the build environment.  The installed libgtk2.0-0 package is version 2.12.0-1ubuntu3 and gtk2-engines is 1:2.12.1-0ubuntu1.

Comment 9

[Matthew Gregan [:kinetik]]

Oh, sayrer, are you running a 32- or 64-bit browser build on your x64 install?  For reference, mine was 64-bit.

Comment 10

[Robert Sayre]

64-bit. hmm.

Comment 11

[Karl Tomlinson (:karlt)]

==16777== 907,344 bytes in 795 blocks are possibly lost in loss record 270 of 276
==16777==    at 0x4C20E3D: memalign (vg_replace_malloc.c:332)
==16777==    by 0x4C20E96: posix_memalign (vg_replace_malloc.c:425)
==16777==    by 0xA132120: (within /usr/lib/libglib-2.0.so.0.1400.1)
==16777==    by 0xA132F0D: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1400.1)
==16777==    by 0xA133085: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.1400.1)
==16777==    by 0x9ECE9EE: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.1400.1)
==16777==    by 0x9EB622C: (within /usr/lib/libgobject-2.0.so.0.1400.1)
==16777==    by 0x9EB4663: g_object_newv (in /usr/lib/libgobject-2.0.so.0.1400.1)
==16777==    by 0x9EB50AB: g_object_new_valist (in /usr/lib/libgobject-2.0.so.0.1400.1)
==16777==    by 0x9EB52E0: g_object_new (in /usr/lib/libgobject-2.0.so.0.1400.1)
==16777==    by 0x5AC5627: moz_drawingarea_new (in /home/sayrer/dev/opt_firefox/mozilla/ff-opt-libxul/toolkit/library/libxul.so)
...
==16777==    by 0x598FBA7: nsWindowWatcher::OpenWindow(nsIDOMWindow*, char const*, char const*, char const*, nsISupports*, nsIDOMWindow**) (in /home/sayrer/dev/opt_firefox/mozilla/ff-opt-libxul/toolkit/library/libxul.so)


g_slice_alloc is a slice allocator
http://library.gnome.org/devel/glib/unstable/glib-Memory-Slices.html

The memory obtained through posix_memalign will be reused by other callers to g_slice_alloc, so it is not necessarily moz_drawingarea_new that is keeping this chunk of memory reserved (though if this stack occurs several times that may increase the likelihood that moz_drawingarea_new is a problem).

To get meaningful info on the leak, either valgrind needs to be told that g_slice_alloc is an allocator, or G_SLICE=always-malloc needs to be in the environment.
http://library.gnome.org/devel/glib/unstable/glib-running.html#G_SLICE

Comment 12

[Reed Loden [:reed]]

Why is this RESOLVED INCOMPLETE?

Comment 13

[Karl Tomlinson (:karlt)]

I resolved this INCOMPLETE because the leak evidence in attachment 295642 [details] isn't really enough to implicate MozDrawingareas.  If more evidence comes to light, then feel free to reopen.

(In tracemalloc logs that I've seen, the only evidence of [small] leaks associated with moz_drawingareas involve [single] registration of the GType through g_type_register_static and [with the same stack] instantiation of the class through g_type_class_ref.  Classes registered with g_type_register_static are never completely unref'ed.)