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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



There's a systemtap script you can use that Alex wrote a little while
ago. Try that out.

http://blogs.gnome.org/alexl/2010/01/04/tracing-glib/
http://tecnocode.co.uk/2010/07/13/reference-count-debugging-with-systemtap/

Hopefully this gets you on the right track!

On Sun, Oct 7, 2012 at 12:13 AM, Tristan Van Berkom <tvb@xxxxxxxxx> wrote:
> 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



-- 
  Jasper
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list


[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux