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
