[gst-devel] refdbg and gst
jgreen at users.sourceforge.net
Tue Sep 28 15:45:37 CEST 2004
On Tue, 2004-09-28 at 14:22 +0200, Stefan Kost wrote:
> hi hi,
> I've been using refdbg  since a few days on my project and it helped me a
> lot. After fixing a lot of ref-count probelms a few persist and they seem to be
> inside gst at a very low level.
> Can anyone of the core developers please try it to and either confirm that there
> are bugs or tell me that I can safely ignore them.
> Things I have tried are:
> refdbg -c "btnum=8 ; r0=B:error" gst-launch sinesrc ! osssink
> refdbg -c "btnum=8 ; r0=B:error" gst-launch sinesrc ! audioconvert ! esdsink
> refdbg -c "btnum=8 ; r0=B:error" gst-launch fakesrc ! fakesink
> and then
> refdbg -c "btnum=8 ; r0=B:error" gdb --args gst-launch fakesrc ! fakesink
> The "btnum=8" instructs refdbg to print a backtrace with 8 lines and the
> "r0=..." is a rule that says "break on Error".
> The error I get it that gst refs something that already has been destroyed.
> Unfortunately gdb is not able to get a backtrace for whatever reason :-(
>  http://refdbg.sf.net
Hey, nice to hear of someone using refdbg besides myself :) I
originally developed it for my own projects (Swami/libInstPatch/etc) but
saw that it could be very useful for others as well. The testing process
of refdbg itself has been only slight to moderate, so some warnings that
you see might be bugs in refdbg. It can be a very useful tool though for
tracking down GObject reference counting bugs. If you think you have
found a case where refdbg reports a false positive I'd really like to
know about it.
Concerning backtraces. Internally refdbg relies on the standard glibc
backtrace() function which is rather wimpy at times. It would be nice to
get better code to unroll the stack (something like what valgrind uses).
As to GDB and backtraces, I have found its often a case of optimization
flags like -fomit-frame-pointer that cause GDB to fail miserably on back
traces (over and above the obvious -g debug symbols flag). Cheers!
Josh Green <jgreen at users.sourceforge.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the gstreamer-devel