DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:subject:to:cc:references:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=LShuW/tSjd+zwXwr
	D3RPkt6vaSAjWhuuhqxe+oXyx58ajiCbe/HkgOp4sy4Kno9l9SwjYpPmAw+zeB2T
	iB3i9c33cZ8hG+/RTkPdGjbbMa+PDogcKDA8NyMO9Yy4oBSj+XvEs6VDRG0clYX7
	eKa6Wy6rxqxQaxhQ0eJz+HVJ1tM=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
From: Jon Turney <jon.turney@dronecode.org.uk>
Subject: Re: cin and read(*,*) not waiting for kbd input in gdb
To: The Cygwin Mailing List <cygwin@cygwin.com>
Cc: "Rockefeller, Harry" <Harry.Rockefeller@flightsafety.com>
References: <552d8b06cb6e431fb00f581c7853b795@vsrv060ex01.ssd.fsi.com> <ba72d46a-1f44-e313-5ce9-e496e1adbf6c@dronecode.org.uk> <78b75f32051c4c83a43b0adc2c65dbb5@vsrv060ex01.ssd.fsi.com> <691b0f69130c46ad90ea6ddf93d3b1be@vsrv060ex01.ssd.fsi.com> <c0b0940393fe43068fd6bca4f9ba4263@vsrv060ex01.ssd.fsi.com> <c002bc64-e66d-0c4f-4bf4-c9741dd3cd98@dronecode.org.uk> <2c4e575b182d46bba28e9fd688a0c9e7@vsrv060ex01.ssd.fsi.com>
Message-ID: <0fb72531-bb5b-1637-9f29-3e74d24ed4c0@dronecode.org.uk>
Date: Wed, 29 Jan 2020 13:07:05 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2
MIME-Version: 1.0
In-Reply-To: <2c4e575b182d46bba28e9fd688a0c9e7@vsrv060ex01.ssd.fsi.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 28/01/2020 15:40, Rockefeller, Harry wrote:
> Since you and I appear to be the only ones interested in this particular problem I brought this off the
> Cygwin list, at least for now.

Please don't do this.

https://cygwin.com/problems.html#personal-email

> You are correct, and I am able to reproduce this myself as well using gdb 8.1.1-1.
> In gdb 8.1.1-1 here is the same test case with stdin running correctly using a continue after the breakpoint that caused the gdb internal error before. > Thread 1 "test1" hit Breakpoint 1, test1 () at test1.f:9
> 9                read(*,*) cycle_length
> Breakpoint 2 at 0x3df9bb3e0: file /usr/src/debug/gcc-7.4.0-1/libgfortran/io/unix.c, line 277.
> (gdb) c
> Continuing.
> 
> Thread 1 "test1" hit Breakpoint 2, _gfortrani_flush_if_preconnected (s=0x80004e300) at /usr/src/debug/gcc-7.4.0-1/libgfortran/io/unix.c:277
> 277         fflush (stdin);
> (gdb) c
> Continuing.
> -1
> STOP normal termination
> [Thread 8904.0x2f34 exited with code 0]
> [Thread 8904.0x1e78 exited with code 0]
> [Inferior 1 (process 8904) exited normally]
> (gdb)
> 
> Now, reloading gdb 8.2.1-1:

Again, I don't seem to be able to reproduce this:

> $ gdb ./test1
> GNU gdb (GDB) (Cygwin 8.2.1-1) 8.2.1
> Copyright (C) 2018 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-pc-cygwin".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
>     <http://www.gnu.org/software/gdb/documentation/>.
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ./test1...done.
> (gdb) b test1.f:9
> Breakpoint 1 at 0x100401140: file test1.f, line 9.
> (gdb) r
> Starting program: /wip/test1
>  Supply the equivalent of run time in seconds.
> (Note: a negative run time will stop run):
> Thread 1 "test1" hit Breakpoint 1, test () at test1.f:9
> 9                   read(*,*) cycle_length
> (gdb) b unix.c:271
> Breakpoint 2 at 0x3e11eb3c0: file /usr/src/debug/gcc-7.4.0-1/libgfortran/io/unix.c, line 272.
> (gdb) c
> Continuing.
> 
> Thread 1 "test1" hit Breakpoint 2, _gfortrani_flush_if_preconnected (s=0x80003b160) at /usr/src/debug/gcc-7.4.0-1/libgfo
> rtran/io/unix.c:272
> 272     {
> (gdb) c
> Continuing.
> -1
> STOP normal termination
> [Inferior 1 (process 10024) exited normally]
> (gdb)

> The only thing changed was the gdb version.  I don't know how to proceed from here.
> Can you tell if this is a gdb or a "Cygwin implementation of" gdb problem?

I'm not sure what the distinction you are making here is?  The problem 
almost certainly exists in upstream gdb, without the few patches which 
are applied in the Cygwin package of gdb.

I'd guess that this is problem is due to upstream changes in gdb, 
interacting with bugs or limitations of Cygwin.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple