From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18602 invoked by alias); 16 Jan 2005 10:54:20 -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 18568 invoked from network); 16 Jan 2005 10:54:13 -0000 Received: from unknown (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org with SMTP; 16 Jan 2005 10:54:13 -0000 Received: from farnswood.snap.net.nz (p247-tnt2.snap.net.nz [202.124.108.247]) by viper.snap.net.nz (Postfix) with ESMTP id 8D58220F8A7 for ; Sun, 16 Jan 2005 23:54:11 +1300 (NZDT) Received: by farnswood.snap.net.nz (Postfix, from userid 501) id 82F1E628AD; Sun, 16 Jan 2005 10:47:06 +0000 (GMT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16874.17961.812024.375273@farnswood.snap.net.nz> Date: Sun, 16 Jan 2005 10:54:00 -0000 To: gdb@sources.redhat.com Subject: internal-error: insert_step_resume_breakpoint_at_sal In-Reply-To: <16804.1142.136766.593493@farnswood.snap.net.nz> References: <16804.1142.136766.593493@farnswood.snap.net.nz> X-SW-Source: 2005-01/txt/msg00079.txt.bz2 Following my earlier e-mail (Wed, 24 Nov 2004 16:48:06 +1300): > Debugging emacs in CVS with gdb in CVS, I often get an error if I try to step > through the program after setting a breakpoint: > > To reproduce: > > gdb emacs > GNU gdb 6.3.50_2004-11-24-cvs > ... > (gdb) b Fsplit_window (for example) > (gdb) run > > `C-x 2' in Emacs > > (gdb) n > infrun.c:2763: internal-error: insert_step_resume_breakpoint_at_sal: Assertion `step_resume_breakpoint == NULL' failed. > A problem internal to GDB has been detected, infrun.c (in insert_step_resume_breakpoint_at_sal) says: /* There should never be more than one step-resume breakpoint per thread, so we should never be setting a new step_resume_breakpoint when one is already active. */ However, in this case (and presumably others too) there is more than one step-resume breakpoint. insert_step_resume_breakpoint_at_sal is called at infrun.c:1931 and then infrun.c:1949 through handle_inferior_event: First time: #0 insert_step_resume_breakpoint_at_sal (sr_sal= {symtab = 0x0, section = 0x0, line = 0, pc = 134872212, end = 0}, sr_id= {stack_addr = 3221220224, code_addr = 134872206, special_addr = 0, stack_addr_p = 1, code_addr_p = 1, special_addr_p = 0}) at infrun.c:2671 During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at#1 0x080fbe4f in insert_step_resume_breakpoint_at_frame (return_frame=0x0) at infrun.c:2699 #2 0x080fa6c3 in handle_inferior_event (ecs=0xbffff180) at infrun.c:1931 #3 0x080f9cb8 in wait_for_inferior () at infrun.c:974 Second time: #0 internal_error (file=0x8221657 "infrun.c", line=2668, string=0x81ef7a1 "%s: Assertion `%s' failed.") at utils.c:789 #1 0x080fbdda in insert_step_resume_breakpoint_at_sal (sr_sal= {symtab = 0x0, section = 0x0, line = 0, pc = 134872212, end = 0}, sr_id= {stack_addr = 3221220224, code_addr = 134872206, special_addr = 0, stack_addr_p = 1, code_addr_p = 1, special_addr_p = 0}) at infrun.c:2672 #2 0x080fbe4f in insert_step_resume_breakpoint_at_frame (return_frame=0x0) at infrun.c:2699 #3 0x080fa677 in handle_inferior_event (ecs=0xbffff180) at infrun.c:1949 #4 0x080f9cb8 in wait_for_inferior () at infrun.c:974 Previously GDB just issued a warning, but there never seemed to be any harm in dropping the old step_resume_breakpoint. How about replacing: gdb_assert (step_resume_breakpoint == NULL); in insert_step_resume_breakpoint_at_sal with: warning ("GDB bug: infrun.c (wait_for_inferior): dropping old step_resume breakpoint"); which used to be in check_for_old_step_resume_breakpoint? Nick