[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GDB problems



Chris Plummer wrote:

Sorry about all the emails. A couple of these issues are ones that I've
had on my Qube 2 for a while and I was hoping would disappear on my
Indy, but no such luck.

I'm having problems using GDB on an application of mine. I get a SIGTRAP
before main() is even entered, and the pc is bad. The output of a gdb
session is below. Also, if I attach to the already running app, I have
similar problems with SIGTRAP. The only thing that seems to work is
debugging a core, and even that doesn't always work (sometimes it thinks
the pc is 0)

My program is somewhat big, but if you saw my previous email, you saw
that there was no problem debugging even larger apps like xemacs and emacs.

BTW, this happens on both the Indy and Qube 2. Any help would be greatly
appreciated. This problem is a really big priority for me, because if I
can't debug this app with gdb, I'm hosed! :)

Thanks,

Chris Plummer


indy-01$ gdb testapp
GNU gdb 2002-04-01-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "mips-linux"...
(gdb) br main
Breakpoint 1 at 0x606f0c: file main.c, line 18.
(gdb) run
Starting program: /usr/bin/testapp [New Thread 1024 (LWP 18281)]

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 1024 (LWP 18281)]
warning: Warning: GDB can't find the start of the function at 0xffffffff.

   GDB is unable to find the start of the function at 0xffffffff
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
   This problem is most likely caused by an invalid program counter or
stack pointer.
   However, if you think GDB should simply search farther back
from 0xffffffff for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
0xffffffff in ?? ()
(gdb) bt
#0  0xffffffff in ?? ()
#1  0x2aab73c8 in _dl_init () from /lib/ld.so.1
Cannot access memory at address 0x38
(gdb) p $pc
$1 = -1
(gdb)


This can happen if you have a large static/global array which can't be satisfied




Reply to: