From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 545 invoked by alias); 22 Jun 2012 19:18:45 -0000 Received: (qmail 530 invoked by uid 22791); 22 Jun 2012 19:18:44 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 22 Jun 2012 19:18:28 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q5MJISt2020336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 22 Jun 2012 15:18:28 -0400 Received: from host2.jankratochvil.net (ovpn-116-33.ams2.redhat.com [10.36.116.33]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q5MJIO6M005614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 22 Jun 2012 15:18:26 -0400 Date: Fri, 22 Jun 2012 19:18:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Do not respawn signals, take 2. Message-ID: <20120622191823.GA10515@host2.jankratochvil.net> References: <20120622145525.27114.25720.stgit@brno.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120622145525.27114.25720.stgit@brno.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-06/txt/msg00730.txt.bz2 On Fri, 22 Jun 2012 16:55:25 +0200, Pedro Alves wrote: > @@ -1950,9 +1954,24 @@ resume_lwp (struct lwp_info *lp, int step) > } > > static int > -resume_callback (struct lwp_info *lp, void *data) > +linux_nat_resume_callback (struct lwp_info *lp, void *data) > { > - resume_lwp (lp, 0); > + enum gdb_signal signo = GDB_SIGNAL_0; > + > + if (lp->stopped) > + { > + struct thread_info *thread; > + > + thread = find_thread_ptid (lp->ptid); > + if (thread != NULL) > + { > + if (signal_pass_state (thread->suspend.stop_signal)) This signal_pass_state check seems redundant to me. At least remote.c append_pending_thread_resumptions does not do the check and infrun.c already seems to pre-clear it: /* If this signal should not be seen by program, give it zero. Used for debugging signals. */ else if (!signal_program[tp->suspend.stop_signal]) tp->suspend.stop_signal = GDB_SIGNAL_0; > + signo = thread->suspend.stop_signal; > + thread->suspend.stop_signal = GDB_SIGNAL_0; > + } > + } > + > + resume_lwp (lp, 0, signo); > return 0; > } > [...] > @@ -2856,6 +2875,8 @@ stop_wait_callback (struct lwp_info *lp, void *data) > { > int status; > > + gdb_assert (lp->resumed); > + > status = wait_lwp (lp); > if (status == 0) > return 0; This assertion happens sometimes. https://bugzilla.redhat.com/show_bug.cgi?id=808404 The assertion seems right to me, IIRC you also concluded it indicates a Linux kernel bug where sometimes SIGSTOP is not generated by PTRACE_ATTACH. Keeping the assertion may give more clue in bugreports when the Linux kernel bug happens but AFAIK the FSF GDB policy is against such "more assertion for better bugreports" policy. But it is also true I do not know what GDB will do if the kernel bug happens and this assertion is not in place. Therefore for FSF GDB the general approach is it should be removed. Thanks, Jan