This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Single-step runaway
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Robin Rowe <rower at MovieEditor dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 1 Aug 2003 09:05:27 -0400
- Subject: Re: Single-step runaway
- References: <002101c357fb$7a516bb0$0200a8c0@tbird>
On Fri, Aug 01, 2003 at 12:06:48AM -0700, Robin Rowe wrote:
> I have a program that gdb doesn't seem to be able to enforce a breakpoint
> on. As I single step through my code gdb suddenly takes the bit in its teeth
> and slips away to run the program forward as though I had issued continue.
> When I reach a particular function call in my code it simply takes off and
> runs to completion (it's a batch process) rather than stepping into the call
> as it should. If I stepi half a dozen times I can get inside the call and
> single-stepping mostly works from there forward -- but not consistently so.
> As a debugger it is almost unusable with this flaw. It would be faster to
> use printf.
>
> Other gdb users tell me they have encountered erratic behaviour like this
> from time to time. Is this a known bug? Why is it happening? What can be
> done about it?
>
> FYI, there is nothing exotic about the function call that runs away. It is a
> statically linked library C call. That library uses C++ internally, but the
> interface is an extern "C" function call that passes a straight C struct.
> All the code involved is code I wrote myself and compiled at the same time.
> I'm running on RedHat 7.1. Tried compiling gdb 5.3 from source, but no
> difference.
>
> Suggestions?
This usually means that GDB's stack unwinder has gotten confused. You
may want to try using a compiler recent enough to emit DWARF CFI
information (GCC 3.2/3.3 should do; I don't know whether RH7.1's
compiler does or not) and a snapshot of GDB 6.0. That combination
seems to be rather more robust.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer