From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7034 invoked by alias); 29 Oct 2004 17:43:51 -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 7026 invoked from network); 29 Oct 2004 17:43:49 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 29 Oct 2004 17:43:49 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id i9THhnMp032343 for ; Fri, 29 Oct 2004 13:43:49 -0400 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i9THhnr28947; Fri, 29 Oct 2004 13:43:49 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id D05B1129D8B; Fri, 29 Oct 2004 13:42:15 -0400 (EDT) Message-ID: <418280F3.1090502@redhat.com> Date: Sat, 30 Oct 2004 14:54:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Andreas Schwab Cc: gdb@sources.redhat.com Subject: Re: infrun.c:2642: internal-error: insert_step_resume_breakpoint_at_sal: Assertion `step_resume_breakpoint == NULL' failed. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00425.txt.bz2 Andreas Schwab wrote: > I'm getting this assertion failure on ia64-linux when stepping after a > breakpoint with a signal also being delivered. Both calls to > insert_step_resume_breakpoint_at_sal are coming from the two calls to > insert_step_resume_breakpoint_at_frame in handle_inferior_event. In both > calls the actual address where the breakpoint is to be set is the same. I > haven't been able to come up with a small test case, this happens while > debugging Emacs. The sig* tests check this edge case. For the other architectures I investigated, it was tracked down to kernel bugs. For instance, ptrace(STEP,SIGNAL) was implemented as ptrace(CONT,SIGNAL). Suggest looking upstream, we've (Red Hat) have been pushing fixes for other key architectures ;-) Andrew