Re: [PATCH] The gcore command hangs without a terminal

[Jan Kratochvil <jan.kratochvil@redhat.com>]

Hi Daniel,

the patch was more an optimization, it is not a GDB bug, as I see it now.


On Tue, 27 Mar 2007 18:20:41 +0200, Daniel Jacobowitz wrote:
> On Sun, Feb 25, 2007 at 01:26:42PM +0100, Jan Kratochvil wrote:
> > Hi,
> > 
> > The function `attach_command' sets up the terminal by calling
> > target_terminal_inferior ().  This makes gcore(1) to lock up when being run
> > without its controlling terminal.
> > 
> > I do not find a reason for this terminal setup as GDB does not share its
> > input/output with the application in the mode of external attached program.
> 
> 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.


> 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.



Thanks,
Jan