From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14754 invoked by alias); 1 Aug 2003 13:05:32 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 14738 invoked from network); 1 Aug 2003 13:05:31 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 1 Aug 2003 13:05:31 -0000 Received: from drow by nevyn.them.org with local (Exim 4.20 #1 (Debian)) id 19iZb5-0003B4-Fj; Fri, 01 Aug 2003 09:05:27 -0400 Date: Fri, 01 Aug 2003 13:05:00 -0000 From: Daniel Jacobowitz To: Robin Rowe Cc: gdb@sources.redhat.com Subject: Re: Single-step runaway Message-ID: <20030801130527.GA12183@nevyn.them.org> Mail-Followup-To: Robin Rowe , gdb@sources.redhat.com References: <002101c357fb$7a516bb0$0200a8c0@tbird> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002101c357fb$7a516bb0$0200a8c0@tbird> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-08/txt/msg00003.txt.bz2 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