From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16132 invoked by alias); 20 Jun 2006 18:19:10 -0000 Received: (qmail 16095 invoked by uid 22791); 20 Jun 2006 18:19:07 -0000 X-Spam-Check-By: sourceware.org Received: from Unknown (HELO brical.or.uni-bonn.de) (131.220.141.99) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 20 Jun 2006 18:19:04 +0000 Received: from wse04.or.uni-bonn.de (bg-1.or.uni-bonn.de [131.220.141.100]) by brical.or.uni-bonn.de (Postfix) with ESMTP id 6C970AC9B for ; Tue, 20 Jun 2006 20:34:41 +0200 (CEST) Received: from certa.vlsi.uni-bonn.de (certa-en0.vlsi.uni-bonn.de [192.168.143.187]) by wse04.or.uni-bonn.de (Postfix) with ESMTP id CAE2DE95E for ; Tue, 20 Jun 2006 20:20:49 +0200 (CEST) From: Christoph Bartoschek To: gdb@sourceware.org Subject: Re: GDB does not respond to CTRL+Z and CTRL+C Date: Tue, 20 Jun 2006 18:31:00 -0000 User-Agent: KMail/1.8.2 References: <200606201827.25482.bartoschek@or.uni-bonn.de> <200606202002.05813.bartoschek@or.uni-bonn.de> <20060620180453.GA30199@nevyn.them.org> In-Reply-To: <20060620180453.GA30199@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606202018.56169.bartoschek@or.uni-bonn.de> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00153.txt.bz2 > Then it is likely that your program is blocking the signal. GDB > doesn't handle either directly; it forwards them to the program and > lets the OS handle delivery. I do not think that we block the signal. However, I have to check the code. But this does not explain why I am able to use CTRL+Z and CTRL+C as intended after sending SIGSTOP directly to GDB and foregrounding it again. CTRL+Z and CTRL+C are only ignored until GDB receives the first SIGSTOP via the kill command. If the signals are blocked, then I would expect that GDB behaves similarly before and after SIGSTOP. If the signals are really blocked, how should one interrupt debugging to set breakpoints for example? Christoph Bartoschek