Comments on: Reference count debugging with gdb

By: Arun Raghavan

Arun Raghavan — Wed, 14 Jul 2010 05:34:58 +0000

Just for completeness - the point of using the watchpoint is that most hardware supports this construct, so it works a lot faster.

By: Arun Raghavan

Arun Raghavan — Wed, 14 Jul 2010 05:33:29 +0000

Maybe I got what you're doing wrong, but I usually set a watchpoint on the object's refcount. Something like:

p object (fugly, but this makes a gdb variable, say $1, with the address of object, so your watchpoint is not tied to the symbol 'object')
watch ((GObject*)$1)->ref_count

By: Reference count debugging with systemtap — drboblog

Reference count debugging with systemtap — drboblog — Tue, 13 Jul 2010 22:39:27 +0000

[...] got some really helpful comments on yesterday’s post about reference count debugging with gdb which enabled me to get [...]

By: Mark Wielaard

Mark Wielaard — Tue, 13 Jul 2010 08:31:27 +0000

The soon to be released SystemTap 1.3 should at least print the "module" (share library name) of the last frame of the backtrace (plus address of course). That way you can at least see why SystemTap couldn't unwind further. As Frank says then you could provide SystemTap with that shared library hint through -d. Also 1.3 has --ldd which makes SystemTap pick up everything ldd knows about a program. There were also a couple of plain bug fixes in the unwinder that should improve the output.

If that isn't enough maybe we can teach systemtap about pkg-config files to pick up which shared libraries are likely to be used in a gnome program. Or is there some other hints about dynamically loaded libraries that systemtap should know about?

By: Philip Withnall

Philip Withnall — Tue, 13 Jul 2010 07:17:02 +0000

That's good to hear; I look forward to being able to use them. Thanks for all the great work on systemtap.

By: Philip Withnall

Philip Withnall — Tue, 13 Jul 2010 07:14:19 +0000

gdb couldn't find the symbol when I tried that (and I had compiled GLib with --enable-debug=yes).

By: Benjamin Otte

Benjamin Otte — Tue, 13 Jul 2010 07:08:01 +0000

You can compile glib with --enable-debug and then set the g_trap_object_ref variable in gdb. That'll make glib do the breakpoints for you. See http://git.gnome.org/browse/glib/tree/gobject/gobject.c#n2483 for detais.

By: Frank Ch. Eigler

Frank Ch. Eigler — Tue, 13 Jul 2010 01:40:12 +0000

"[systemtap] worked, in that my probes were correctly run and correctly highlighted each reference/dereference of the class I was interested in, but printing a backtrace only extended to the g_object_ref()/g_object_unref() call, and no further." Some major improvements to backtracing are coming soon to stap land. It's possible though that the only thing you were lacking were some '-d /path/to/shlib -d /bin/foo' options to preload unwind data into the systemtap probe module.

By: Joe Buck

Joe Buck — Tue, 13 Jul 2010 01:29:00 +0000

It's an old technique. The trick is to try to figure out how to choose the breakpoints so that gdb runs as little as possible, since it's slow. If there is a breakpoint with a condition, gdb wakes up every time, checks the condition, and restarts the program if it isn't satisfied, which can be expensive (though it's a lot faster than doing it by hand). Enabling and disabling breakpoints can sometimes help.