This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Using gdb Is there anyway to check the stack before the call to abort then raise
- From: Daniel Jacobowitz <drow at false dot org>
- To: shanevolpe at gmail dot com
- Cc: gdb at sourceware dot org
- Date: Tue, 27 Feb 2007 14:39:32 -0500
- Subject: Re: Using gdb Is there anyway to check the stack before the call to abort then raise
- References: <8c7950360702271134t6a14ebedo8c5e9a08a5320c14@mail.gmail.com>
On Tue, Feb 27, 2007 at 02:34:05PM -0500, shanevolpe@gmail.com wrote:
> (gdb) backtrace 20
> #0 0x00000000 in ?? ()
> #1 0x00013c80 in Audio::BackgroundThreadFunction (this=0x499c0) at
> /home/richardr/wcd3100l/arm/lifecor/apps/shell/src/audio.cpp:485
> #2 0x00013f20 in BackgroundAudioThread (arg=0x499c0) at
> /home/richardr/wcd3100l/arm/lifecor/apps/shell/src/audio.cpp:605
> I received the above backtrace after an error occured in my program.
> Why cant GDB determine the last function call (if I did not word this
> right, I appologize, I am looking for an explanation for why #0 is
> 0x000000000 in ??). Is there anyway to catch this info.
Normally this means you called a function pointer, which pointed to
NULL. It should be apparent if you look at the line above where it
came from. If it isn't, set a breakpoint there and see what happens.
> (gdb) bt
> #0 0x4039aa24 in raise () from /lib/libc.so.6
> #1 0x4039bd5c in abort () from /lib/libc.so.6 Backtrace stopped:
> frame did not save the PC
Make sure that your Linux distributor's debug info packages for glibc
are installed, and that your GDB is configured to use them.
--
Daniel Jacobowitz
CodeSourcery