From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18350 invoked by alias); 27 Mar 2007 16:44:14 -0000 Received: (qmail 18296 invoked by uid 22791); 27 Mar 2007 16:44:12 -0000 X-Spam-Check-By: sourceware.org Received: from return.false.org (HELO return.false.org) (66.207.162.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 27 Mar 2007 17:44:09 +0100 Received: from return.false.org (localhost [127.0.0.1]) by return.false.org (Postfix) with ESMTP id 2D0014B26F; Tue, 27 Mar 2007 11:44:08 -0500 (CDT) Received: from caradoc.them.org (dsl093-172-095.pit1.dsl.speakeasy.net [66.93.172.95]) by return.false.org (Postfix) with ESMTP id ED5174B267; Tue, 27 Mar 2007 11:44:07 -0500 (CDT) Received: from drow by caradoc.them.org with local (Exim 4.63) (envelope-from ) id 1HWEmF-00038R-HW; Tue, 27 Mar 2007 12:44:07 -0400 Date: Tue, 27 Mar 2007 16:44:00 -0000 From: Daniel Jacobowitz To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] The gcore command hangs without a terminal Message-ID: <20070327164407.GF3452@caradoc.them.org> Mail-Followup-To: Jan Kratochvil , gdb-patches@sourceware.org References: <20070225122641.GA25884@host0.dyn.jankratochvil.net> <20070327162041.GA3452@caradoc.them.org> <20070327163915.GA4742@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070327163915.GA4742@host0.dyn.jankratochvil.net> User-Agent: Mutt/1.5.14+cvs20070313 (2007-03-13) 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: 2007-03/txt/msg00256.txt.bz2 On Tue, Mar 27, 2007 at 06:39:16PM +0200, Jan Kratochvil wrote: > > Unfortunately I think this is the wrong place to fix it. You're > > commenting out a call to target_terminal_inferior, but there are lots > > of other calls to this function - including one any time we continue > > the program. > > If we `continue' the inferior it may access its terminal and so we must set it > up for the inferior. It is right there. But the `gcore' command IMO does not > need to access the inferior's terminal as it never lets the inferior to run. > Accessing the inferior's terminal should be postponed to the time where the > inferior could use it. If we attach to a program, it should have its own controlling terminal, not the same as GDB's. So why should we do anything with the terminal at all? Perhaps all the terminal operations should be suppressed if we're attached. > > target_terminal_inferior is a call eventually to terminal_inferior. > > This checks gdb_has_a_terminal (). How are you calling GDB without a > > controlling terminal that still lets gdb_has_a_terminal () return > > true? That's probably the right place to fix it. > > You are right there is primarily a bug in the customer's application (which > spawns the `gcore' command). It should either provide no terminal or > a terminal with appropriate access rights. An alternative would be to detect whatever had gone wrong in GDB and avoid fiddling with the terminal if this happens. -- Daniel Jacobowitz CodeSourcery