Single-step runaway

Single-step runaway

[Robin Rowe]

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?

Thanks,

Robin
---------------------------------------------------------------------------
Robin.Rowe@MovieEditor.com   Hollywood, California
www.CinePaint.org   Free motion picture and still image editing software

Re: Single-step runaway

[Daniel Jacobowitz]

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