Re: bug in gdb tty command on cygwin

[Christopher Faylor <cgf at redhat dot com>]

[Reply to set to mailing list - beware]
On Sat, Jan 04, 2003 at 10:00:48PM +0000, Steven O'Brien wrote:
>>>With this patch I am able to build and run a fully functional anjuta
>>IDE>on cygwin-xfree86. Without it anjuta's debugger will not work on
>>cygwin.>I am sure that other X11 GUIs for gdb on cygwin would also
>>benefit from>this patch.
>>>
>>>The patch moves one line of code in just one file that is only used in
>>>the cygwin build; and code that is only invoked if the --tty option or
>>>tty command are invoked.
>>
>>I saw your patch but since it invoked a "Huh?" response, it required
>>some study.  I don't see any correlation between your description of
>>the problem and your proposed patch.  I don't know why closing the tty
>>later would cause the kind of problem you were talking about, so it
>>isn't an obvious "plop it right in" kind of patch.
>
>You are right, the problem should not logically occur because of this.
>However, the problem is real is is cured by my patch. In any case,
>closing the tty after Create Process is logically incorrect, because the
>inferior then inherits this fd which could concievably change its
>behaviour. My patch therefore is a correction for an error in the gdb
>code. As a bonus, the patch also fixes the broken gdb tty command, which
>is what I need for cygwin-xfree86 anjuta.

I understand that there is an extra fd open.  I remember making a
conscious decision to keep it open and I really should have added a
comment about it because I don't remember why now.  Given the way cygwin
allocates ttys it is not necessarily a bad thing to keep an fd around
associated with the tty.  One reason, is that if the process closes
stdin/stdout/stderr and reopens the tty it may not get the tty that it
thinks it is getting.

Regardless, I'm never comfortable with patches that "seem to work fine
for me" when there is no explanation as to why.

Actually, the more I think about it, the more I think that the current
implementation could fail in strange ways due to process startup races
even with the current method for doing closes.

>After more testing, I have found that the problem does not occur when
>the target tty is a windows console running bash. It does not matter
>whether gdb is running in a console or pseudo-terminal. My testing
>previously had used only rxvt (both X11 and native windows), xterm and
>gnome-terminal, all of which cause the failure. I guess this might
>indicate some problem with cygwin pty code. But the gdb tty command has
>been broken for a long time, so its unlikely that the recent cygwin tty
>changes are to blame.

No, the gdb command hasn't been broken for a long time.  The tty command
wasn't implemented until 2002-09-13.  An official version of gdb.exe
which supported it was released on 2002-12-16.  I did test it repeatedly
in the console tty case and it seems to work fine.  I didn't think to
try it on rxvt, though.

cgf