Re: how to debug a program when the session freezes

[Elijah Newren <newren gmail com>]

On 1/8/06, Rod Butcher <rbutcher hyenainternet com> wrote:
> Can somebody tell me how to get a gdb trace when the app I'm debugging
> freezes my X session ? I'm running gnome-system-monitor from a
> terminal : gdb gnome-system-monitor which freezes up the X session when
> I click on the top menu line. The only way I can get out is by by
> al-ctl-f1 and killing the X session from the linux command line. How do
> I send the gdb output to a file for later retrieval, and is it possible
> to get the stack trace some other way, without X ?

Yes, you can get a stack trace of an X application outside of X.  On
occasion I have to do the same for debugging something in a Metacity
patch I'm writing.  After (re)starting metacity, I switch to a virtual
terminal and do a 'ps -ef | grep metacity | grep -v grep', take the
PID number (the value in the second column), and then run 'gdb
./src/metacity <PID>'.  As soon as I get the gdb prompt, I type "cont"
to let metacity continue running, switch back to X, do whatever is
necessary to cause it to crash, and then switch back to the virtual
terminal to inspect the stack trace.

If all I want is a stack trace, though, and I'm on a machine with
loads of memory (and slow execution of the program isn't an issue)
then sometimes it's easier to use valgrind as it detects segfaults
(along with tons of other problems) and adds a stack trace to the log
file automatically in those cases.

If the program you are using isn't crashing but just locking up or
using lots of CPU in some kind of infinite loop, then you have to do
something slightly different.  valgrind isn't much use there.  You can
still use the gdb instructions above (just switch to the virtual
terminal when it seems to be in its deadlock state and hit ctrl-c,
then get your backtrace).  However, for these kinds of things, it's
often a lot better to run a profiler (e.g. oprofile, sysprof) and get
the output from that.


Hope that helps,
Elijah