Re: Could anyone give a short info on tracking refcounting bugs?

[Tristan Van Berkom <tvb gnome org>]

On Sun, Oct 7, 2012 at 3:34 AM, marcin saepia net <marcin saepia net> wrote:
> Dear all,
>
> I am googling for a tool for debugging refcount bugs in my GObject-based apps.
>
> I've found refdbg, but unfortunately, on ubuntu 12.04 instructions
> from this readme [1] do not work. There is only one package,
> libglib2.0-0-refdbg which seems to be just a GLib build with slightly
> changed configure options, and it is obviously libglib not libgobject.
>
> So I've compiled refdbg by myself.
>
>
>
> It throws errors...
>
> $ LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/refdbg refdbg src/myapp -c
> config.xml
> /usr/bin/refdbg: 113: /usr/bin/refdbg: Syntax error: Bad for loop variable
>
> ...but I've found that it just prepends command with
> LD_PRELOAD=/usr/lib/librefdbg.so
>
>
>
> but running it manually also gives an error
>
> $ LD_PRELOAD=/usr/lib/librefdbg.so
> LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/refdbg refdbg src/myapp -c
> config.xml
>
> RefDbg 1.2 init
>
> (process:447): RefDbg-CRITICAL **: LD_PRELOAD function override not
> working. Need to build glib with --disable-visibility? (See README),
> aborting..
>
>
> I've found that ubuntu's libglib2.0-0-refdbg package builder appends
> only --disable-Bsymbolic option to glib, and --disable-visibility was
> intentionally removed according to its debian changelog.
>
> So I've manually updated debian/rules to rebuild the package and add
> --disable-visibility but glib's configure scripts throws an error
>
> configure: WARNING: unrecognized options: --disable-visibility
>
> I am stuck.
>
>
>
> What am I doing wrong?
>
> Is there any civilized way to debug GObject refcount bugs?
>
>
> What exactly means "intercepted" in the last sentence from official
> "Debugging reference count problems" page from docs [2]?

Hi,
   I've never heard of this tool but certainly would like to use it
in the next rare case that a bad ref-counting bug catches me ;-)

By 'intercepting' I presume it means it logs the stack trace for
every g_object_ref()/g_object_unref() call, and filters the output
according to a particular object which you know to have some
imbalanced ref count at the end of the day.

Traditional / tedious method for tracking this sort of thing:

   a.) You of course need to know what object is either leaking
        or unreffed after finalization (which GObject will have
        an imbalanced ref).

   b.) Start your program under gdb and set a break point where
        the object will be created

   c.) After seeing your program create the object initially,
        Set a watchpoint on it's ref count, i.e.:
        (gdb) watch  ((GObject *)0xADDRESS)->ref_count

   d.) Pull out your trusty notebook and note down every time
        that object's ref count changes, watch the stack traces as
        they go by (or tell gdb to log output to a file and just
        type 'where'/'continue' repeatedly until the program finishes
        or crashes).

       There will be a lot of noise from extra safety  ref/unref calls
       from g_signal_emit(), property notifications
        and such, try to filter them out and find the higher level
        places where the object was reffed/unreffed from application
        code.



After creating this report by hand, it's usually quite simple to see
where your object is over/under referenced (but it certainly is nice
to see that there is some efforts made towards automating the
creation of such a report).

Cheers,
           -Tristan