456864 - hook GLib/GObject reference counting functions into nsTraceRefcnt leak logging

Status: NEW

(Core :: Widget: Gtk, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

For a long time, I've wanted to hook up the GLib reference count functions (g_object_ref, g_object_unref) into nsTraceRefcnt leak logging, so that we can:
 * detect leaks of GLib objects more readily
 * debug those leaks more easily, using make-tree.pl, etc.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: approach that requires glib hooks (glib diff)

I have two patches lying around, dated September 26, 2003, from an approach for doing this that required patching glib.  Except for having to use a custom glib, this is slightly simpler than my newer approach since it requires hooking into fewer places.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: approach that requires glib hooks (mozilla diff)

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: work in progress for approach without glib modifications

Here's the beginning of an approach with no glib modifications.

This is a little bit tricky for two reasons;

(1) libgobject plays tricks with visibility, so we not only need to hook into g_object_ref and g_object_unref, but we need to hook into every public function that exposes unbalanced reference counts to the caller.  (This is because it uses hidden symbols internally and then aliases a default-visibility symbol to the same function.)  I haven't done this yet.

(2) getting the first reference at the right time is a bit tricky.  The approach I took here is a bit too late, since nsTraceRefcnt gets confused unless the first AddRef it gets for an object is the AddRef to 1.  If I could take the same approach to replace g_object_init (I think that's the relevant instance_init, although it's a parameter short, so maybe I'm confused) instead of g_object_constructor then things would be better -- assuming I can find a way to do that.

Comment 4

[Karl Tomlinson (:karlt)]

(In reply to comment #3)
> (1) libgobject plays tricks with visibility, so we not only need to hook into
> g_object_ref and g_object_unref, but we need to hook into every public function
> that exposes unbalanced reference counts to the caller.  (This is because it
> uses hidden symbols internally and then aliases a default-visibility symbol to
> the same function.)

I guess they don't build with -Bsymbolic then, but that would produce similar issues.

> (2) getting the first reference at the right time is a bit tricky.  The
> approach I took here is a bit too late, since nsTraceRefcnt gets confused
> unless the first AddRef it gets for an object is the AddRef to 1.

A quicky way to get around that could be to call NS_LogAddRef with
ref_count - 1 in g_object_ref until g_object_get_qdata finds a marker that is set when real_g_object_constructor returns.  The effects of g_object_set_qdata on memory use may distort other metrics though...

Comment 5

[Karl Tomlinson (:karlt)]

Perhaps if we only hooked _GObjectClass::constructor() and _GObjectClass::finalize(), it would at least allow us to detect leaks more easily, even though we wouldn't get info about all the points where references are taken.