On Sun, Oct 7, 2012 at 3:34 AM, marcin@xxxxxxxxxx <marcin@xxxxxxxxxx> 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
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list
