Re: Rare character glitch in pty?

Re: Rare character glitch in pty?

[Thomas Wolff]

I had reported this to the the main cygwin list:

Am 20.07.2023 um 08:33 schrieb Thomas Wolff via Cygwin:
> There was a report that on switching terminal windows with the mouse,
> focus event reports (as enabled with ESC[?1004h) would sometimes get 
> mangled.
> This is further described in issue reports to mintty/wsltty 
> (https://github.com/mintty/wsltty/issues/335) and also to tmux 
> (https://github.com/tmux/tmux/issues/3601).
>
> I could reproduce the issue without either of tmux or WSL. However, it 
> happens only once in a few hundred instances:
> The escape sequence is changed so that the initial ESC is replaced by 
> one of the two subsequent characters, so instead of ESC[O, either of 
> [[O or sometimes O[O would be sent to the foreground application.
>
> I traced the issue down to the pty that connects mintty and its client 
> application, verified that the correct sequence is passed into write() 
> at the pty and the mangled sequence appears at read() in the client 
> process. In addition to a minimised test program that behaves like 
> `cat -v`, I also also put the test output directly into the client 
> process within the mintty code.
> This leaves the only conclusion that the issue must be happening 
> somehow within pty handling, maybe in the context of some timing 
> condition or Windows messages being passed to mintty.
> Anyhow, I was about to prepare testing with older mintty versions, in 
> case I overlooked something, when the OP reported that the issue does 
> not happen with cygwin 3.2.0.
> Is there any recent change that could possibly cause such weird 
> behaviour?
> Thomas
>

I have now automated the test case to chase the issue and associate it 
with a cygwin version. As unlikely as it may appear, results suggest 
that there is a case within the pty handling that may change sequences 
sent through it once in a while, more likely on a system under heavy load.
I took some of the latest cygwin snapshots (by the way, there are no 
newer ones on the snapshots page):
I can reproduce the issue with
     3.3.5-341.x86_64.snap 2022-02-17 11:53 UTC
while it did not occur with
     3.4.0-341.x86_64.snap 2022-01-27 14:34 UTC
Weird enough, the failing newer one is a cygwin 3.3.5 although the older 
one is a 3.4.0 version.

Checking the git log around that time, there are a number of changes 
related to pty as listed below. I added some ! or ? marks to indicate 
more or less likely commits to be a culprit of this issue, judged on 
commit messages and browsing of code changes.

I would also try to identify a commit more precisely but unfortunately 
the cygwin build process seems broken for me as it does not create the 
dll anymore...

Thomas


commit 2f2b91550547001b005393097c5a4328451343d6
Author: Takashi Yano <takashi.yano@nifty.ne.jp>
Date:   Thu Feb 24 00:57:37 2022 +0900

     Cygwin: pty, console: Add a workaround for GDB SIGINT handling.

     - The inferior of the GDB cannot be continued after SIGINT even
       though nopass option is set. This seems because cygwin GDB does
       not support hooking cygwin signal. Therefore, a workaround for
       GDB is added. With this patch, only CTRL_C_EVENT is sent to the
       GDB inferior by Ctrl-C and sending SIGINT is omitted. Note that
       "handle SIGINT (no)pass" command does not take effect even with
       or without this patch.

commit 2cab4d0bb4af5ad7ec97914068d5fa1b8954909c
Author: Takashi Yano <takashi.yano@nifty.ne.jp>
Date:   Tue Feb 15 23:23:50 2022 +0900
?
     Cygwin: pty, console: Refactor the code processing special keys.

     - This patch commonize the code which processes special keys in pty
       and console to improve maintanancibility. As a result, some small
       bugs have been fixed.

commit bed1add783a13b3304b1625b962707f89e90e323
Author: Takashi Yano <takashi.yano@nifty.ne.jp>
Date:   Sun Feb 13 05:12:18 2022 +0900

     Cygwin: pty: Fix a bug in tty_min::segpgid().

     - In tty_min::setpgid(), a pointer to fhandler instance is casted to
       fhandler_pty_slave and accessed even if terminal is not a pty slave.
       This patch fixes the issue.

commit c4704c7c204e377859f657a3b06c112133adff09
Author: Takashi Yano <takashi.yano@nifty.ne.jp>
Date:   Sun Feb 13 02:16:32 2022 +0900

     Cygwin: pty: Discard input in from_master_nat pipe on signal as well.

     - Currently, pty discards input only in from_master pipe on signal.
       Due to this, if pty is started without pseudo console support and
       start a non-cygwin process from cmd.exe, type adhead input is not
       discarded on signals such as Ctrl-C. This patch fixes the issue.

commit b958e1f03acd1732bb0a433a589efb645458aac4
Author: Takashi Yano <takashi.yano@nifty.ne.jp>
Date:   Thu Feb 10 17:47:51 2022 +0900
?
     Cygwin: pty: Revise the code to wait for completion of forwarding.

     - With this patch, the code to wait for completion of forwarding of
       output from non-cygwin app is revised so that it can more reliably
       detect the completion.

commit bddd9c1c417e97791c44241cf94753e90464501c
Author: Takashi Yano <takashi.yano@nifty.ne.jp>
Date:   Thu Feb 10 17:22:11 2022 +0900
!?
     Cygwin: pty: Prevent deadlock on echo output.

     - If the slave process writes a lot of text output, doecho() can
       cause deadlock. This is because output_mutex is held in slave::
       write() and if WriteFile() is blocked due to pipe full, doecho()
       tries to acquire output_mutex and gets into deadlock. With this
!      patch, the deadlock is prevented on the sacrifice of atomicity
       of doecho().

commit b04aea00f1bb503dcc364c83ee3ef3da3bc1305e
Author: Takashi Yano <takashi.yano@nifty.ne.jp>
Date:   Sat Feb 12 17:51:55 2022 +0900
??
     Cygwin: pty: Pass Ctrl-Z (EOF) to non-cygwin apps with disable_pcon.

     - Previously, non-cygwin app running in pty started without pseudo
       console support was suspended by Ctrl-Z rather than sending EOF.
       Even worse, suspended app could not be resumed by fg command. With
       this patch, Ctrl-Z (EOF for non-cygwin apps) is passed to non-cygwin
       app instead of suspending that app. This patch also handles Ctrl-\
       (QUIT) and Ctrl-D (EOF) as well.

commit c05c36a7c8af5e97fa379abb7571ed35a0088e98
Author: Takashi Yano <takashi.yano@nifty.ne.jp>
Date:   Thu Feb 10 16:53:47 2022 +0900
??
     Cygwin: pty, console: Fix Ctrl-C handling for non-cygwin apps.

     - Currently, if cat is started from cmd.exe which is started in cygwin
       console, Ctrl-C terminates not only cat but also cmd.exe. This also
       happens in pty in which pseudo console is disabled. This patch fixes
       the issue.

commit 909ed837ccb932ea70f71cc41891fa2c8143133f
Author: Takashi Yano <takashi.yano@nifty.ne.jp>
Date:   Fri Jan 14 19:35:12 2022 +0900
??
     Cygwin: pty: Fix race issue between closing and opening master.

     - If the from_master is closed before cleaning up other pipes, such
       as from_slave_nat, the same pty may be allocated and pty master may
       try to open the pipe which is not closed yet, and it will fail.
       This patch fixes the issue.

commit 3af461092e7ee9b76f3a1c18a6d95ed6e226df81
Author: Takashi Yano <takashi.yano@nifty.ne.jp>
Date:   Thu Jan 13 19:44:43 2022 +0900
!?
     Cygwin: pty: Stop closing and recreating attach_mutex.

     - Closing attach_mutex and recreating it causes the race issue
       between pty and console codes. With this patch, attach_mutex
       is created only once in a process which opens pty, and never
       closed in order to avoid this issue.

     Addresses:
https://cygwin.com/pipermail/cygwin-developers/2021-December/012548.html

commit 4f490c4cef8fd527642dbb5ea5373b373193a49b
Author: Takashi Yano <takashi.yano@nifty.ne.jp>
Date:   Thu Jan 13 18:18:00 2022 +0900

     Cygwin: pty: Fix memory leak in master_fwd_thread.

     - If master_fwd_thread is terminated by cygthread::terminate_thread(),
       the opportunity to release tmp_pathbuf is missed, resulting in a
       memory leak. This patch fixes the issue.

commit aa49985245e4e5b278778b0a47f6ce83cceb4ad4
Author: Takashi Yano <takashi.yano@nifty.ne.jp>
Date:   Thu Jan 13 18:16:31 2022 +0900
?
     Cygwin: pty, console: Fix deadlock in GDB regarding mutex.

     - GDB inferior may be suspended while the inferior grabs mutex.
       This causes deadlock in terminal I/O. With this patch, timeout
       for waiting mutex is set to 0 for the debugger process when the
       process calls CreateProcess() with DEBUG_PROCESS flag to avoid
       deadlock. This may cause the race issue in GDB, however, there
       is no other way than that.

     Addresses:
https://cygwin.com/pipermail/cygwin-developers/2021-December/012542.html

Re: Rare character glitch in pty?

[Corinna Vinschen]

On Aug  1 23:05, Thomas Wolff wrote:
> I took some of the latest cygwin snapshots (by the way, there are no newer
> ones on the snapshots page):

Snapshots are no longer produced.  You should download the latest
test versions via setup.


Corinna

cygwin build

[Thomas Wolff]

Am 01.08.2023 um 23:27 schrieb Corinna Vinschen:
> On Aug  1 23:05, Thomas Wolff wrote:
>> I took some of the latest cygwin snapshots (by the way, there are no newer
>> ones on the snapshots page):
> Snapshots are no longer produced.  You should download the latest
> test versions via setup.
So what if I need an older version?

> I would also try to identify a commit more precisely but unfortunately 
> the cygwin build process seems broken for me as it does not create the 
> dll anymore...
I run configure and make in the git clone directory. It takes a while 
and terminates without error but there is no dll in the tree as it used 
to be until ~ 2 years ago.
I also followed the instructions in the FAQ which look a bit different, 
no dll.
All support tools mentioned in the FAQ are installed.

Please enable me to build cygwin again.
Thomas

>
>
> Corinna

Re: cygwin build

[Takashi Yano]

On Wed, 2 Aug 2023 08:36:03 +0200
Thomas Wolff wrote:
> Am 01.08.2023 um 23:27 schrieb Corinna Vinschen:
> > On Aug  1 23:05, Thomas Wolff wrote:
> >> I took some of the latest cygwin snapshots (by the way, there are no newer
> >> ones on the snapshots page):
> > Snapshots are no longer produced.  You should download the latest
> > test versions via setup.
> So what if I need an older version?
> 
> > I would also try to identify a commit more precisely but unfortunately 
> > the cygwin build process seems broken for me as it does not create the 
> > dll anymore...
> I run configure and make in the git clone directory. It takes a while 
> and terminates without error but there is no dll in the tree as it used 
> to be until ~ 2 years ago.
> I also followed the instructions in the FAQ which look a bit different, 
> no dll.
> All support tools mentioned in the FAQ are installed.
> 
> Please enable me to build cygwin again.

Did you run autogen.sh in winsup directory before configure?


-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: cygwin build

[Corinna Vinschen]

On Aug  2 08:36, Thomas Wolff wrote:
> 
> 
> Am 01.08.2023 um 23:27 schrieb Corinna Vinschen:
> > On Aug  1 23:05, Thomas Wolff wrote:
> > > I took some of the latest cygwin snapshots (by the way, there are no newer
> > > ones on the snapshots page):
> > Snapshots are no longer produced.  You should download the latest
> > test versions via setup.
> So what if I need an older version?

It's all documented:

https://cygwin.com/git.html
https://cygwin.com/faq.html#faq.programming.building-cygwin

Creating snapshots was a really outdated method.  It relied on on a
non-standard, third-party script system, which started to fray at the
edges.  So we switched to an automated build system which creates test
releases on every Cygwin-related change to the git repository instead.
When we did that I think I even made a matching announcement on the
mailing list.


Corinna

Re: cygwin build

[Thomas Wolff]

Am 02.08.2023 um 10:09 schrieb Corinna Vinschen:
> On Aug  2 08:36, Thomas Wolff wrote:
>>
>> Am 01.08.2023 um 23:27 schrieb Corinna Vinschen:
>>> On Aug  1 23:05, Thomas Wolff wrote:
>>>> I took some of the latest cygwin snapshots (by the way, there are no newer
>>>> ones on the snapshots page):
>>> Snapshots are no longer produced.  You should download the latest
>>> test versions via setup.
>> So what if I need an older version?
> It's all documented:
>
> https://cygwin.com/git.html
> https://cygwin.com/faq.html#faq.programming.building-cygwin
Thanks. Actually package mingw zlib was missing (when I installed it, it 
got mistargeted to my parallel test installation).
It now worked, kind of, with some build errors after producing the dll.
However, after I checked out an older git commit, rebuild fails again:
make[4]: Entering directory 
'/cygdrive/c/tmp/newlib-cygwin/build/x86_64-pc-cygwin/newlib/libc'
make[4]: *** No rule to make target 'all'.  Stop.
So I'm not getting another dll after changing the git reference.

>
> Creating snapshots was a really outdated method.  It relied on on a
> non-standard, third-party script system, which started to fray at the
> edges.  So we switched to an automated build system which creates test
> releases on every Cygwin-related change to the git repository instead.
> When we did that I think I even made a matching announcement on the
> mailing list.
Setup offers 3.5.0 versions but not older ones. So a working build 
process would be essential for certain bug analysis.
Thomas

>
>
> Corinna

Re: cygwin build

[Jon Turney]

On 03/08/2023 09:21, Thomas Wolff wrote:
> Am 02.08.2023 um 10:09 schrieb Corinna Vinschen:
>> On Aug  2 08:36, Thomas Wolff wrote:
>>>
>>> Am 01.08.2023 um 23:27 schrieb Corinna Vinschen:
>>>> On Aug  1 23:05, Thomas Wolff wrote:
>>>>> I took some of the latest cygwin snapshots (by the way, there are 
>>>>> no newer
>>>>> ones on the snapshots page):
>>>> Snapshots are no longer produced.  You should download the latest
>>>> test versions via setup.
>>> So what if I need an older version?
>> It's all documented:
>>
>> https://cygwin.com/git.html
>> https://cygwin.com/faq.html#faq.programming.building-cygwin
> Thanks. Actually package mingw zlib was missing (when I installed it, it 
> got mistargeted to my parallel test installation).
> It now worked, kind of, with some build errors after producing the dll.

Nobody can take any useful action about those "build errors" if you keep 
them secret.

> However, after I checked out an older git commit, rebuild fails again:
> make[4]: Entering directory 
> '/cygdrive/c/tmp/newlib-cygwin/build/x86_64-pc-cygwin/newlib/libc'
> make[4]: *** No rule to make target 'all'.  Stop.
> So I'm not getting another dll after changing the git reference.
> 

Yeah, this seems a bit optimistic expecting that to work going backwards 
over the various recent build system changes.

Maybe things would work if you'd initially configured with 
--enable-maintainer-mode (off by default for newlib), but even then, 
sometimes the only solution is to scrub the build directory and start 
afresh.

Re: cygwin build

[Thomas Wolff]

Am 03.08.2023 um 15:12 schrieb Jon Turney:
> On 03/08/2023 09:21, Thomas Wolff wrote:
>> Am 02.08.2023 um 10:09 schrieb Corinna Vinschen:
>>> On Aug  2 08:36, Thomas Wolff wrote:
>>>>
>>>> Am 01.08.2023 um 23:27 schrieb Corinna Vinschen:
>>>>> On Aug  1 23:05, Thomas Wolff wrote:
>>>>>> I took some of the latest cygwin snapshots (by the way, there are 
>>>>>> no newer
>>>>>> ones on the snapshots page):
>>>>> Snapshots are no longer produced.  You should download the latest
>>>>> test versions via setup.
>>>> So what if I need an older version?
>>> It's all documented:
>>>
>>> https://cygwin.com/git.html
>>> https://cygwin.com/faq.html#faq.programming.building-cygwin
>> Thanks. Actually package mingw zlib was missing (when I installed it, 
>> it got mistargeted to my parallel test installation).
>> It now worked, kind of, with some build errors after producing the dll.
>
> Nobody can take any useful action about those "build errors" if you 
> keep them secret.
>
Sure, I just mentioned it and didn't post details as it wasn't essential 
for the discussed issue. Anyway, here are the final error message I 
often encounter:

make[5]: Entering directory 
'/cygdrive/c/tmp/newlib-cygwin/build/x86_64-pc-cygwin/winsup/utils'
   CXXLD    dumper.exe
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../lib/libbfd.a(compress.o): 
in function `decompress_contents':
/usr/src/debug/binutils-2.41-1/bfd/compress.c:514:(.text+0x20d): 
undefined reference to `ZSTD_decompress'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
/usr/src/debug/binutils-2.41-1/bfd/compress.c:516:(.text+0x215): 
undefined reference to `ZSTD_isError'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../lib/libbfd.a(compress.o): 
in function `bfd_compress_section_contents':
/usr/src/debug/binutils-2.41-1/bfd/compress.c:653:(.text+0x11e4): 
undefined reference to `ZSTD_compress'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
/usr/src/debug/binutils-2.41-1/bfd/compress.c:658:(.text+0x11f1): 
undefined reference to `ZSTD_isError'
collect2: error: ld returned 1 exit status
make[5]: *** [Makefile:603: dumper.exe] Error 1
make[5]: Leaving directory 
'/cygdrive/c/tmp/newlib-cygwin/build/x86_64-pc-cygwin/winsup/utils'
make[4]: *** [Makefile:872: all-recursive] Error 1
make[4]: Leaving directory 
'/cygdrive/c/tmp/newlib-cygwin/build/x86_64-pc-cygwin/winsup/utils'
make[3]: *** [Makefile:512: all] Error 2
make[3]: Leaving directory 
'/cygdrive/c/tmp/newlib-cygwin/build/x86_64-pc-cygwin/winsup/utils'
make[2]: *** [Makefile:395: all-recursive] Error 1
make[2]: Leaving directory 
'/cygdrive/c/tmp/newlib-cygwin/build/x86_64-pc-cygwin/winsup'
make[1]: *** [Makefile:9464: all-target-winsup] Error 2
make[1]: Leaving directory '/cygdrive/c/tmp/newlib-cygwin/build'
make: *** [Makefile:883: all] Error 2

Re: cygwin build

[Takashi Yano]

On Sat, 5 Aug 2023 20:18:43 +0200
Thomas Wolff wrote:
> Am 03.08.2023 um 15:12 schrieb Jon Turney:
> > On 03/08/2023 09:21, Thomas Wolff wrote:
> >> Am 02.08.2023 um 10:09 schrieb Corinna Vinschen:
> >>> On Aug  2 08:36, Thomas Wolff wrote:
> >>>>
> >>>> Am 01.08.2023 um 23:27 schrieb Corinna Vinschen:
> >>>>> On Aug  1 23:05, Thomas Wolff wrote:
> >>>>>> I took some of the latest cygwin snapshots (by the way, there are 
> >>>>>> no newer
> >>>>>> ones on the snapshots page):
> >>>>> Snapshots are no longer produced.  You should download the latest
> >>>>> test versions via setup.
> >>>> So what if I need an older version?
> >>> It's all documented:
> >>>
> >>> https://cygwin.com/git.html
> >>> https://cygwin.com/faq.html#faq.programming.building-cygwin
> >> Thanks. Actually package mingw zlib was missing (when I installed it, 
> >> it got mistargeted to my parallel test installation).
> >> It now worked, kind of, with some build errors after producing the dll.
> >
> > Nobody can take any useful action about those "build errors" if you 
> > keep them secret.
> >
> Sure, I just mentioned it and didn't post details as it wasn't essential 
> for the discussed issue. Anyway, here are the final error message I 
> often encounter:
> 
> make[5]: Entering directory 
> '/cygdrive/c/tmp/newlib-cygwin/build/x86_64-pc-cygwin/winsup/utils'
>    CXXLD    dumper.exe
> /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
> /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../lib/libbfd.a(compress.o): 
> in function `decompress_contents':
> /usr/src/debug/binutils-2.41-1/bfd/compress.c:514:(.text+0x20d): 
> undefined reference to `ZSTD_decompress'
> /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
> /usr/src/debug/binutils-2.41-1/bfd/compress.c:516:(.text+0x215): 
> undefined reference to `ZSTD_isError'
> /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
> /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../lib/libbfd.a(compress.o): 
> in function `bfd_compress_section_contents':
> /usr/src/debug/binutils-2.41-1/bfd/compress.c:653:(.text+0x11e4): 
> undefined reference to `ZSTD_compress'
> /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
> /usr/src/debug/binutils-2.41-1/bfd/compress.c:658:(.text+0x11f1): 
> undefined reference to `ZSTD_isError'
> collect2: error: ld returned 1 exit status
> make[5]: *** [Makefile:603: dumper.exe] Error 1
> make[5]: Leaving directory 
> '/cygdrive/c/tmp/newlib-cygwin/build/x86_64-pc-cygwin/winsup/utils'
> make[4]: *** [Makefile:872: all-recursive] Error 1
> make[4]: Leaving directory 
> '/cygdrive/c/tmp/newlib-cygwin/build/x86_64-pc-cygwin/winsup/utils'
> make[3]: *** [Makefile:512: all] Error 2
> make[3]: Leaving directory 
> '/cygdrive/c/tmp/newlib-cygwin/build/x86_64-pc-cygwin/winsup/utils'
> make[2]: *** [Makefile:395: all-recursive] Error 1
> make[2]: Leaving directory 
> '/cygdrive/c/tmp/newlib-cygwin/build/x86_64-pc-cygwin/winsup'
> make[1]: *** [Makefile:9464: all-target-winsup] Error 2
> make[1]: Leaving directory '/cygdrive/c/tmp/newlib-cygwin/build'
> make: *** [Makefile:883: all] Error 2

That happened to me before.

Install libzstd-devel.
Remove
./etc/config.cache
./x86_64-pc-cygwin/newlib/config.cache
./x86_64-pc-cygwin/winsup/config.cache
Re-run ./configure && make.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: cygwin build

[Thomas Wolff]

Am 06.08.2023 um 00:20 schrieb Takashi Yano:
> On Sat, 5 Aug 2023 20:18:43 +0200
> Thomas Wolff wrote:
>> Am 03.08.2023 um 15:12 schrieb Jon Turney:
>>> On 03/08/2023 09:21, Thomas Wolff wrote:
>>>> Am 02.08.2023 um 10:09 schrieb Corinna Vinschen:
>>>>> On Aug  2 08:36, Thomas Wolff wrote:
>>>>>> Am 01.08.2023 um 23:27 schrieb Corinna Vinschen:
>>>>>>> On Aug  1 23:05, Thomas Wolff wrote:
>>>>>>>> I took some of the latest cygwin snapshots (by the way, there are
>>>>>>>> no newer
>>>>>>>> ones on the snapshots page):
>>>>>>> Snapshots are no longer produced.  You should download the latest
>>>>>>> test versions via setup.
>>>>>> So what if I need an older version?
>>>>> It's all documented:
>>>>>
>>>>> https://cygwin.com/git.html
>>>>> https://cygwin.com/faq.html#faq.programming.building-cygwin
>>>> Thanks. Actually package mingw zlib was missing (when I installed it,
>>>> it got mistargeted to my parallel test installation).
>>>> It now worked, kind of, with some build errors after producing the dll.
>>> Nobody can take any useful action about those "build errors" if you
>>> keep them secret.
>>>
>> Sure, I just mentioned it and didn't post details as it wasn't essential
>> for the discussed issue. Anyway, here are the final error message I
>> often encounter:
>>
>> make[5]: Entering directory
>> '/cygdrive/c/tmp/newlib-cygwin/build/x86_64-pc-cygwin/winsup/utils'
>>     CXXLD    dumper.exe
>> /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
>> /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../lib/libbfd.a(compress.o):
>> in function `decompress_contents':
>> /usr/src/debug/binutils-2.41-1/bfd/compress.c:514:(.text+0x20d):
>> undefined reference to `ZSTD_decompress'
>> /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
>> /usr/src/debug/binutils-2.41-1/bfd/compress.c:516:(.text+0x215):
>> undefined reference to `ZSTD_isError'
>> /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
>> /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../lib/libbfd.a(compress.o):
>> in function `bfd_compress_section_contents':
>> /usr/src/debug/binutils-2.41-1/bfd/compress.c:653:(.text+0x11e4):
>> undefined reference to `ZSTD_compress'
>> /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
>> /usr/src/debug/binutils-2.41-1/bfd/compress.c:658:(.text+0x11f1):
>> undefined reference to `ZSTD_isError'
>> collect2: error: ld returned 1 exit status
>> make[5]: *** [Makefile:603: dumper.exe] Error 1
>> make[5]: Leaving directory
>> '/cygdrive/c/tmp/newlib-cygwin/build/x86_64-pc-cygwin/winsup/utils'
>> make[4]: *** [Makefile:872: all-recursive] Error 1
>> make[4]: Leaving directory
>> '/cygdrive/c/tmp/newlib-cygwin/build/x86_64-pc-cygwin/winsup/utils'
>> make[3]: *** [Makefile:512: all] Error 2
>> make[3]: Leaving directory
>> '/cygdrive/c/tmp/newlib-cygwin/build/x86_64-pc-cygwin/winsup/utils'
>> make[2]: *** [Makefile:395: all-recursive] Error 1
>> make[2]: Leaving directory
>> '/cygdrive/c/tmp/newlib-cygwin/build/x86_64-pc-cygwin/winsup'
>> make[1]: *** [Makefile:9464: all-target-winsup] Error 2
>> make[1]: Leaving directory '/cygdrive/c/tmp/newlib-cygwin/build'
>> make: *** [Makefile:883: all] Error 2
> That happened to me before.
>
> Install libzstd-devel.
> Remove
> ./etc/config.cache
> ./x86_64-pc-cygwin/newlib/config.cache
> ./x86_64-pc-cygwin/winsup/config.cache
> Re-run ./configure && make.
Yes, thanks, that dependency is missing in the FAQ.

Re: cygwin build

[Jon Turney]

On 05/08/2023 19:18, Thomas Wolff wrote:
> 
> 
> Am 03.08.2023 um 15:12 schrieb Jon Turney:
>> On 03/08/2023 09:21, Thomas Wolff wrote:
>>> Am 02.08.2023 um 10:09 schrieb Corinna Vinschen:
>>>> On Aug  2 08:36, Thomas Wolff wrote:
>>>>>
>>>>> Am 01.08.2023 um 23:27 schrieb Corinna Vinschen:
>>>>>> On Aug  1 23:05, Thomas Wolff wrote:
>>>>>>> I took some of the latest cygwin snapshots (by the way, there are 
>>>>>>> no newer
>>>>>>> ones on the snapshots page):
>>>>>> Snapshots are no longer produced.  You should download the latest
>>>>>> test versions via setup.
>>>>> So what if I need an older version?
>>>> It's all documented:
>>>>
>>>> https://cygwin.com/git.html
>>>> https://cygwin.com/faq.html#faq.programming.building-cygwin
>>> Thanks. Actually package mingw zlib was missing (when I installed it, 
>>> it got mistargeted to my parallel test installation).
>>> It now worked, kind of, with some build errors after producing the dll.
>>
>> Nobody can take any useful action about those "build errors" if you 
>> keep them secret.
>>
> Sure, I just mentioned it and didn't post details as it wasn't essential 
> for the discussed issue. Anyway, here are the final error message I 
> often encounter:
> 
> make[5]: Entering directory 
> '/cygdrive/c/tmp/newlib-cygwin/build/x86_64-pc-cygwin/winsup/utils'
>    CXXLD    dumper.exe
> /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
> /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../lib/libbfd.a(compress.o): 
> in function `decompress_contents':
Ah, right.

This is a problem with the primitive time-travel technology you are using.

dumper relies on libbfd, which since binutils 2.40 relies on zstd.

bfd doesn't provide a .pc file, so the dependencies are explicitly 
listed in our makefile.

You'll either needs to backport the commit [1] which adds zstd to the 
link line to fix this, or also roll back binutils to the version which 
was current when this built...

[1] 
https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=1387ea9f984d5a7aa096a66b67d61dc2cc565d21;hp=588624da2b0a921c7e72d12d19c2ac3321de0326

Re: cygwin build

[Thomas Wolff]

Hi Jon,

Am 06.08.2023 um 20:53 schrieb Jon Turney:
> On 05/08/2023 19:18, Thomas Wolff wrote:
>>
>>
>> Am 03.08.2023 um 15:12 schrieb Jon Turney:
>>> On 03/08/2023 09:21, Thomas Wolff wrote:
>>>> Am 02.08.2023 um 10:09 schrieb Corinna Vinschen:
>>>>> On Aug  2 08:36, Thomas Wolff wrote:
>>>>>>
>>>>>> Am 01.08.2023 um 23:27 schrieb Corinna Vinschen:
>>>>>>> On Aug  1 23:05, Thomas Wolff wrote:
>>>>>>>> I took some of the latest cygwin snapshots (by the way, there 
>>>>>>>> are no newer
>>>>>>>> ones on the snapshots page):
>>>>>>> Snapshots are no longer produced.  You should download the latest
>>>>>>> test versions via setup.
>>>>>> So what if I need an older version?
>>>>> It's all documented:
>>>>>
>>>>> https://cygwin.com/git.html
>>>>> https://cygwin.com/faq.html#faq.programming.building-cygwin
>>>> Thanks. Actually package mingw zlib was missing (when I installed 
>>>> it, it got mistargeted to my parallel test installation).
>>>> It now worked, kind of, with some build errors after producing the 
>>>> dll.
>>>
>>> Nobody can take any useful action about those "build errors" if you 
>>> keep them secret.
>>>
>> Sure, I just mentioned it and didn't post details as it wasn't 
>> essential for the discussed issue. Anyway, here are the final error 
>> message I often encounter:
>>
>> make[5]: Entering directory 
>> '/cygdrive/c/tmp/newlib-cygwin/build/x86_64-pc-cygwin/winsup/utils'
>>    CXXLD    dumper.exe
>> /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
>> /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../lib/libbfd.a(compress.o): 
>> in function `decompress_contents':
> Ah, right.
>
> This is a problem with the primitive time-travel technology you are 
> using.
This was an error when building the current version, no time travel 
involved.
>
> dumper relies on libbfd, which since binutils 2.40 relies on zstd.
Takashi suggested to install libzstd-devel which fixed the issue. It's 
not mentioned in the dependency list at 
https://cygwin.com/faq.html#faq.programming.building-cygwin where I'd 
suggest to add it.
By the way, I'm wondering why the build process needs the manual steps 
and quirks mentioned there. A while ago, I'd just run configure and make 
in the main newlib-cygwin directory. Well it wouldn't allow to make 
another build for 32 bit in the same tree then, but that doesn't exist 
anymore, so what.
As a side note, I'd also suggest to check for dependencies in the 
configure script, to facilitate an early hint. No package I ever built 
seems to do that but it would really help.
Thomas

>
> bfd doesn't provide a .pc file, so the dependencies are explicitly 
> listed in our makefile.
>
> You'll either needs to backport the commit [1] which adds zstd to the 
> link line to fix this, or also roll back binutils to the version which 
> was current when this built...
>
> [1] 
> https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=1387ea9f984d5a7aa096a66b67d61dc2cc565d21;hp=588624da2b0a921c7e72d12d19c2ac3321de0326
>

Re: cygwin build

[Corinna Vinschen]

On Aug  7 08:11, Thomas Wolff wrote:
> Am 06.08.2023 um 20:53 schrieb Jon Turney:
> > dumper relies on libbfd, which since binutils 2.40 relies on zstd.
> Takashi suggested to install libzstd-devel which fixed the issue. It's not
> mentioned in the dependency list at
> https://cygwin.com/faq.html#faq.programming.building-cygwin where I'd
> suggest to add it.

Jon added it to the FAQ in commit 1387ea9f984d5 from February.


Corinna

Re: cygwin build

[Jon Turney]

On 02/08/2023 07:36, Thomas Wolff wrote:
> Am 01.08.2023 um 23:27 schrieb Corinna Vinschen:
>> On Aug  1 23:05, Thomas Wolff wrote:
>>> I took some of the latest cygwin snapshots (by the way, there are no 
>>> newer
>>> ones on the snapshots page):
>> Snapshots are no longer produced.  You should download the latest
>> test versions via setup.
> So what if I need an older version?

I'd suggest maybe start by bisecting old released versions, which are 
available via the Cygwin Time Machine.

(We never promised to keep an infinitely deep history of snapshots, but 
CTM does archive test versions, so going forward we'll have those 
available from it, also)

Re: Rare character glitch in pty?

[Takashi Yano]

On Tue, 1 Aug 2023 23:05:18 +0200
Thomas Wolff wrote:
> I had reported this to the the main cygwin list:
> 
> Am 20.07.2023 um 08:33 schrieb Thomas Wolff via Cygwin:
> > There was a report that on switching terminal windows with the mouse,
> > focus event reports (as enabled with ESC[?1004h) would sometimes get 
> > mangled.
> > This is further described in issue reports to mintty/wsltty 
> > (https://github.com/mintty/wsltty/issues/335) and also to tmux 
> > (https://github.com/tmux/tmux/issues/3601).
> >
> > I could reproduce the issue without either of tmux or WSL. However, it 
> > happens only once in a few hundred instances:
> > The escape sequence is changed so that the initial ESC is replaced by 
> > one of the two subsequent characters, so instead of ESC[O, either of 
> > [[O or sometimes O[O would be sent to the foreground application.
> >
> > I traced the issue down to the pty that connects mintty and its client 
> > application, verified that the correct sequence is passed into write() 
> > at the pty and the mangled sequence appears at read() in the client 
> > process. In addition to a minimised test program that behaves like 
> > `cat -v`, I also also put the test output directly into the client 
> > process within the mintty code.
> > This leaves the only conclusion that the issue must be happening 
> > somehow within pty handling, maybe in the context of some timing 
> > condition or Windows messages being passed to mintty.
> > Anyhow, I was about to prepare testing with older mintty versions, in 
> > case I overlooked something, when the OP reported that the issue does 
> > not happen with cygwin 3.2.0.
> > Is there any recent change that could possibly cause such weird 
> > behaviour?
> > Thomas
> >
> 
> I have now automated the test case to chase the issue and associate it 
> with a cygwin version. As unlikely as it may appear, results suggest 
> that there is a case within the pty handling that may change sequences 
> sent through it once in a while, more likely on a system under heavy load.
> I took some of the latest cygwin snapshots (by the way, there are no 
> newer ones on the snapshots page):
> I can reproduce the issue with
>      3.3.5-341.x86_64.snap 2022-02-17 11:53 UTC
> while it did not occur with
>      3.4.0-341.x86_64.snap 2022-01-27 14:34 UTC
> Weird enough, the failing newer one is a cygwin 3.3.5 although the older 
> one is a 3.4.0 version.

Can you provide the automated test case? I would like to
investigate what is happning.

> Checking the git log around that time, there are a number of changes 
> related to pty as listed below. I added some ! or ? marks to indicate 
> more or less likely commits to be a culprit of this issue, judged on 
> commit messages and browsing of code changes.
> 
> I would also try to identify a commit more precisely but unfortunately 
> the cygwin build process seems broken for me as it does not create the 
> dll anymore...
> 
> Thomas
> 
> 
> commit 2f2b91550547001b005393097c5a4328451343d6
> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
> Date:   Thu Feb 24 00:57:37 2022 +0900
> 
>      Cygwin: pty, console: Add a workaround for GDB SIGINT handling.
> 
>      - The inferior of the GDB cannot be continued after SIGINT even
>        though nopass option is set. This seems because cygwin GDB does
>        not support hooking cygwin signal. Therefore, a workaround for
>        GDB is added. With this patch, only CTRL_C_EVENT is sent to the
>        GDB inferior by Ctrl-C and sending SIGINT is omitted. Note that
>        "handle SIGINT (no)pass" command does not take effect even with
>        or without this patch.
> 
> commit 2cab4d0bb4af5ad7ec97914068d5fa1b8954909c
> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
> Date:   Tue Feb 15 23:23:50 2022 +0900
> ?
>      Cygwin: pty, console: Refactor the code processing special keys.
> 
>      - This patch commonize the code which processes special keys in pty
>        and console to improve maintanancibility. As a result, some small
>        bugs have been fixed.
> 
> commit bed1add783a13b3304b1625b962707f89e90e323
> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
> Date:   Sun Feb 13 05:12:18 2022 +0900
> 
>      Cygwin: pty: Fix a bug in tty_min::segpgid().
> 
>      - In tty_min::setpgid(), a pointer to fhandler instance is casted to
>        fhandler_pty_slave and accessed even if terminal is not a pty slave.
>        This patch fixes the issue.
> 
> commit c4704c7c204e377859f657a3b06c112133adff09
> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
> Date:   Sun Feb 13 02:16:32 2022 +0900
> 
>      Cygwin: pty: Discard input in from_master_nat pipe on signal as well.
> 
>      - Currently, pty discards input only in from_master pipe on signal.
>        Due to this, if pty is started without pseudo console support and
>        start a non-cygwin process from cmd.exe, type adhead input is not
>        discarded on signals such as Ctrl-C. This patch fixes the issue.
> 
> commit b958e1f03acd1732bb0a433a589efb645458aac4
> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
> Date:   Thu Feb 10 17:47:51 2022 +0900
> ?
>      Cygwin: pty: Revise the code to wait for completion of forwarding.
> 
>      - With this patch, the code to wait for completion of forwarding of
>        output from non-cygwin app is revised so that it can more reliably
>        detect the completion.
> 
> commit bddd9c1c417e97791c44241cf94753e90464501c
> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
> Date:   Thu Feb 10 17:22:11 2022 +0900
> !?
>      Cygwin: pty: Prevent deadlock on echo output.
> 
>      - If the slave process writes a lot of text output, doecho() can
>        cause deadlock. This is because output_mutex is held in slave::
>        write() and if WriteFile() is blocked due to pipe full, doecho()
>        tries to acquire output_mutex and gets into deadlock. With this
> !      patch, the deadlock is prevented on the sacrifice of atomicity
>        of doecho().
> 
> commit b04aea00f1bb503dcc364c83ee3ef3da3bc1305e
> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
> Date:   Sat Feb 12 17:51:55 2022 +0900
> ??
>      Cygwin: pty: Pass Ctrl-Z (EOF) to non-cygwin apps with disable_pcon.
> 
>      - Previously, non-cygwin app running in pty started without pseudo
>        console support was suspended by Ctrl-Z rather than sending EOF.
>        Even worse, suspended app could not be resumed by fg command. With
>        this patch, Ctrl-Z (EOF for non-cygwin apps) is passed to non-cygwin
>        app instead of suspending that app. This patch also handles Ctrl-\
>        (QUIT) and Ctrl-D (EOF) as well.
> 
> commit c05c36a7c8af5e97fa379abb7571ed35a0088e98
> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
> Date:   Thu Feb 10 16:53:47 2022 +0900
> ??
>      Cygwin: pty, console: Fix Ctrl-C handling for non-cygwin apps.
> 
>      - Currently, if cat is started from cmd.exe which is started in cygwin
>        console, Ctrl-C terminates not only cat but also cmd.exe. This also
>        happens in pty in which pseudo console is disabled. This patch fixes
>        the issue.
> 
> commit 909ed837ccb932ea70f71cc41891fa2c8143133f
> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
> Date:   Fri Jan 14 19:35:12 2022 +0900
> ??
>      Cygwin: pty: Fix race issue between closing and opening master.
> 
>      - If the from_master is closed before cleaning up other pipes, such
>        as from_slave_nat, the same pty may be allocated and pty master may
>        try to open the pipe which is not closed yet, and it will fail.
>        This patch fixes the issue.
> 
> commit 3af461092e7ee9b76f3a1c18a6d95ed6e226df81
> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
> Date:   Thu Jan 13 19:44:43 2022 +0900
> !?
>      Cygwin: pty: Stop closing and recreating attach_mutex.
> 
>      - Closing attach_mutex and recreating it causes the race issue
>        between pty and console codes. With this patch, attach_mutex
>        is created only once in a process which opens pty, and never
>        closed in order to avoid this issue.
> 
>      Addresses:
> https://cygwin.com/pipermail/cygwin-developers/2021-December/012548.html
> 
> commit 4f490c4cef8fd527642dbb5ea5373b373193a49b
> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
> Date:   Thu Jan 13 18:18:00 2022 +0900
> 
>      Cygwin: pty: Fix memory leak in master_fwd_thread.
> 
>      - If master_fwd_thread is terminated by cygthread::terminate_thread(),
>        the opportunity to release tmp_pathbuf is missed, resulting in a
>        memory leak. This patch fixes the issue.
> 
> commit aa49985245e4e5b278778b0a47f6ce83cceb4ad4
> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
> Date:   Thu Jan 13 18:16:31 2022 +0900
> ?
>      Cygwin: pty, console: Fix deadlock in GDB regarding mutex.
> 
>      - GDB inferior may be suspended while the inferior grabs mutex.
>        This causes deadlock in terminal I/O. With this patch, timeout
>        for waiting mutex is set to 0 for the debugger process when the
>        process calls CreateProcess() with DEBUG_PROCESS flag to avoid
>        deadlock. This may cause the race issue in GDB, however, there
>        is no other way than that.
> 
>      Addresses:
> https://cygwin.com/pipermail/cygwin-developers/2021-December/012542.html
> 
> 


-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: Rare character glitch in pty?

[Thomas Wolff]

[-- Attachment #1: Type: text/plain, Size: 11115 bytes --]



Am 02.08.2023 um 00:35 schrieb Takashi Yano:
> On Tue, 1 Aug 2023 23:05:18 +0200
> Thomas Wolff wrote:
>> I had reported this to the the main cygwin list:
>>
>> Am 20.07.2023 um 08:33 schrieb Thomas Wolff via Cygwin:
>>> There was a report that on switching terminal windows with the mouse,
>>> focus event reports (as enabled with ESC[?1004h) would sometimes get
>>> mangled.
>>> This is further described in issue reports to mintty/wsltty
>>> (https://github.com/mintty/wsltty/issues/335) and also to tmux
>>> (https://github.com/tmux/tmux/issues/3601).
>>>
>>> I could reproduce the issue without either of tmux or WSL. However, it
>>> happens only once in a few hundred instances:
>>> The escape sequence is changed so that the initial ESC is replaced by
>>> one of the two subsequent characters, so instead of ESC[O, either of
>>> [[O or sometimes O[O would be sent to the foreground application.
>>>
>>> I traced the issue down to the pty that connects mintty and its client
>>> application, verified that the correct sequence is passed into write()
>>> at the pty and the mangled sequence appears at read() in the client
>>> process. In addition to a minimised test program that behaves like
>>> `cat -v`, I also also put the test output directly into the client
>>> process within the mintty code.
>>> This leaves the only conclusion that the issue must be happening
>>> somehow within pty handling, maybe in the context of some timing
>>> condition or Windows messages being passed to mintty.
>>> Anyhow, I was about to prepare testing with older mintty versions, in
>>> case I overlooked something, when the OP reported that the issue does
>>> not happen with cygwin 3.2.0.
>>> Is there any recent change that could possibly cause such weird
>>> behaviour?
>>> Thomas
>>>
>> I have now automated the test case to chase the issue and associate it
>> with a cygwin version. As unlikely as it may appear, results suggest
>> that there is a case within the pty handling that may change sequences
>> sent through it once in a while, more likely on a system under heavy load.
>> I took some of the latest cygwin snapshots (by the way, there are no
>> newer ones on the snapshots page):
>> I can reproduce the issue with
>>       3.3.5-341.x86_64.snap 2022-02-17 11:53 UTC
>> while it did not occur with
>>       3.4.0-341.x86_64.snap 2022-01-27 14:34 UTC
>> Weird enough, the failing newer one is a cygwin 3.3.5 although the older
>> one is a 3.4.0 version.
> Can you provide the automated test case? I would like to
> investigate what is happning.

Manual test case:
1. Run `mintty echokey1` with the attached test program that runs like 
`cat -v` and detects the glitch
2. Run a second test window, same setup to increase the hit rate
3. Switch these 2 windows by clicking them in change a few hundred 
times, until the test program outputs "FAIL"

Automated test case:
1. Use the tool TinyTask (https://www.tinytask.net/) to save the 
clicking. Sorry, I didn't manage to replace this with a self-made click 
simulator.
2. Place the 2 test windows in a specific position (e.g. covering the 
two screen halves in a top position)
3. Use the Record function of the tool and click to switch windows a 
dozen times, stop recording
4. Save the sequence as a TinyTask script, or use mine (2w.rec 
attached), better: load the script (Open), then create a standalone test 
executable (button "exe") to create tinytask2w.exe (I can send that to 
you if you like)
5. Optionally, create some background load on your system
6. Minimize other windows in case the test script does not hit the test 
windows
7. Run the test script minptytest (attached) to start the 2 windows and 
run the TinyTask standalone test in a loop; the script detects a marker 
file created by the test program; it also detect premature termination 
of a window (e.g. by hitting ^D in it)

>
>> Checking the git log around that time, there are a number of changes
>> related to pty as listed below. I added some ! or ? marks to indicate
>> more or less likely commits to be a culprit of this issue, judged on
>> commit messages and browsing of code changes.
>>
>> I would also try to identify a commit more precisely but unfortunately
>> the cygwin build process seems broken for me as it does not create the
>> dll anymore...
>>
>> Thomas
>>
>>
>> commit 2f2b91550547001b005393097c5a4328451343d6
>> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
>> Date:   Thu Feb 24 00:57:37 2022 +0900
>>
>>       Cygwin: pty, console: Add a workaround for GDB SIGINT handling.
>>
>>       - The inferior of the GDB cannot be continued after SIGINT even
>>         though nopass option is set. This seems because cygwin GDB does
>>         not support hooking cygwin signal. Therefore, a workaround for
>>         GDB is added. With this patch, only CTRL_C_EVENT is sent to the
>>         GDB inferior by Ctrl-C and sending SIGINT is omitted. Note that
>>         "handle SIGINT (no)pass" command does not take effect even with
>>         or without this patch.
>>
>> commit 2cab4d0bb4af5ad7ec97914068d5fa1b8954909c
>> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
>> Date:   Tue Feb 15 23:23:50 2022 +0900
>> ?
>>       Cygwin: pty, console: Refactor the code processing special keys.
>>
>>       - This patch commonize the code which processes special keys in pty
>>         and console to improve maintanancibility. As a result, some small
>>         bugs have been fixed.
>>
>> commit bed1add783a13b3304b1625b962707f89e90e323
>> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
>> Date:   Sun Feb 13 05:12:18 2022 +0900
>>
>>       Cygwin: pty: Fix a bug in tty_min::segpgid().
>>
>>       - In tty_min::setpgid(), a pointer to fhandler instance is casted to
>>         fhandler_pty_slave and accessed even if terminal is not a pty slave.
>>         This patch fixes the issue.
>>
>> commit c4704c7c204e377859f657a3b06c112133adff09
>> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
>> Date:   Sun Feb 13 02:16:32 2022 +0900
>>
>>       Cygwin: pty: Discard input in from_master_nat pipe on signal as well.
>>
>>       - Currently, pty discards input only in from_master pipe on signal.
>>         Due to this, if pty is started without pseudo console support and
>>         start a non-cygwin process from cmd.exe, type adhead input is not
>>         discarded on signals such as Ctrl-C. This patch fixes the issue.
>>
>> commit b958e1f03acd1732bb0a433a589efb645458aac4
>> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
>> Date:   Thu Feb 10 17:47:51 2022 +0900
>> ?
>>       Cygwin: pty: Revise the code to wait for completion of forwarding.
>>
>>       - With this patch, the code to wait for completion of forwarding of
>>         output from non-cygwin app is revised so that it can more reliably
>>         detect the completion.
>>
>> commit bddd9c1c417e97791c44241cf94753e90464501c
>> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
>> Date:   Thu Feb 10 17:22:11 2022 +0900
>> !?
>>       Cygwin: pty: Prevent deadlock on echo output.
>>
>>       - If the slave process writes a lot of text output, doecho() can
>>         cause deadlock. This is because output_mutex is held in slave::
>>         write() and if WriteFile() is blocked due to pipe full, doecho()
>>         tries to acquire output_mutex and gets into deadlock. With this
>> !      patch, the deadlock is prevented on the sacrifice of atomicity
>>         of doecho().
>>
>> commit b04aea00f1bb503dcc364c83ee3ef3da3bc1305e
>> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
>> Date:   Sat Feb 12 17:51:55 2022 +0900
>> ??
>>       Cygwin: pty: Pass Ctrl-Z (EOF) to non-cygwin apps with disable_pcon.
>>
>>       - Previously, non-cygwin app running in pty started without pseudo
>>         console support was suspended by Ctrl-Z rather than sending EOF.
>>         Even worse, suspended app could not be resumed by fg command. With
>>         this patch, Ctrl-Z (EOF for non-cygwin apps) is passed to non-cygwin
>>         app instead of suspending that app. This patch also handles Ctrl-\
>>         (QUIT) and Ctrl-D (EOF) as well.
>>
>> commit c05c36a7c8af5e97fa379abb7571ed35a0088e98
>> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
>> Date:   Thu Feb 10 16:53:47 2022 +0900
>> ??
>>       Cygwin: pty, console: Fix Ctrl-C handling for non-cygwin apps.
>>
>>       - Currently, if cat is started from cmd.exe which is started in cygwin
>>         console, Ctrl-C terminates not only cat but also cmd.exe. This also
>>         happens in pty in which pseudo console is disabled. This patch fixes
>>         the issue.
>>
>> commit 909ed837ccb932ea70f71cc41891fa2c8143133f
>> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
>> Date:   Fri Jan 14 19:35:12 2022 +0900
>> ??
>>       Cygwin: pty: Fix race issue between closing and opening master.
>>
>>       - If the from_master is closed before cleaning up other pipes, such
>>         as from_slave_nat, the same pty may be allocated and pty master may
>>         try to open the pipe which is not closed yet, and it will fail.
>>         This patch fixes the issue.
>>
>> commit 3af461092e7ee9b76f3a1c18a6d95ed6e226df81
>> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
>> Date:   Thu Jan 13 19:44:43 2022 +0900
>> !?
>>       Cygwin: pty: Stop closing and recreating attach_mutex.
>>
>>       - Closing attach_mutex and recreating it causes the race issue
>>         between pty and console codes. With this patch, attach_mutex
>>         is created only once in a process which opens pty, and never
>>         closed in order to avoid this issue.
>>
>>       Addresses:
>> https://cygwin.com/pipermail/cygwin-developers/2021-December/012548.html
>>
>> commit 4f490c4cef8fd527642dbb5ea5373b373193a49b
>> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
>> Date:   Thu Jan 13 18:18:00 2022 +0900
>>
>>       Cygwin: pty: Fix memory leak in master_fwd_thread.
>>
>>       - If master_fwd_thread is terminated by cygthread::terminate_thread(),
>>         the opportunity to release tmp_pathbuf is missed, resulting in a
>>         memory leak. This patch fixes the issue.
>>
>> commit aa49985245e4e5b278778b0a47f6ce83cceb4ad4
>> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
>> Date:   Thu Jan 13 18:16:31 2022 +0900
>> ?
>>       Cygwin: pty, console: Fix deadlock in GDB regarding mutex.
>>
>>       - GDB inferior may be suspended while the inferior grabs mutex.
>>         This causes deadlock in terminal I/O. With this patch, timeout
>>         for waiting mutex is set to 0 for the debugger process when the
>>         process calls CreateProcess() with DEBUG_PROCESS flag to avoid
>>         deadlock. This may cause the race issue in GDB, however, there
>>         is no other way than that.
>>
>>       Addresses:
>> https://cygwin.com/pipermail/cygwin-developers/2021-December/012542.html
>>
>>
>

[-- Attachment #2: echokeys1.c --]
[-- Type: text/plain, Size: 1625 bytes --]

#include <stdlib.h>
#include <unistd.h>
#include <termios.h>
#include <stdio.h>
#include <sys/select.h>

struct termios saved_tattr;

void
restore_tattr (void)
{
  if (isatty (STDIN_FILENO))
    tcsetattr (STDIN_FILENO, TCSANOW, &saved_tattr);
}

int
main (void)
{
  printf ("end with ^D\n");

  if (isatty (STDIN_FILENO)) {
    tcgetattr (STDIN_FILENO, &saved_tattr);
    struct termios tattr = saved_tattr;

    cfmakeraw(&tattr);

    tcsetattr (STDIN_FILENO, TCSAFLUSH, &tattr);
//    atexit (restore_tattr);
  }
#ifdef use_read
  setbuf (stdout, 0);
#endif

  // enable focus reporting
  printf("\e[?1004h");

  static int nread = 0;
  static unsigned char prevc = 0;

  while (1) {
    unsigned char c;
#ifdef use_read
    int n = read(0, &c, 1); if (n < 1) break;
#else
    c = getchar();
#endif

    switch (c) {
      case 0x00 ... 0x1f:
        printf ("\e[7m^%c\e[m", c + '@');
        //if (c == '\r') printf ("\r\n");
        break;
      case 0x7f:
        printf ("\e[7m^?\e[m");
        break;
      case 0x80 ... 0xFF:
        printf ("\\x%2X", c);
        break;
      default:
        putchar (c);
    }
    // count escape sequences
    if (c == '\e')
      nread++;
    // detect mangled focus report, like [[O or O[O
    if (c == '[' && prevc != '\e') {
      printf("\e[41mFAIL%4d\e[m", nread);
      // touch a marker file (and log nread in it),
      // so a test script can detect it to stop
      char s[99];
      sprintf(s, "echo failed at %d > .minstop", nread);
      system(s);
    }

    if (c == 4) {
      printf ("\r\n"); break;
    }

    prevc = c;
  }
  restore_tattr ();
  return 0;
}

[-- Attachment #3: 2w.rec --]
[-- Type: application/octet-stream, Size: 7360 bytes --]

[-- Attachment #4: minptytest --]
[-- Type: text/plain, Size: 968 bytes --]

#! /bin/dash
# dash rather than bash so it can be recognized in Windows task manager, 
# in case it does not stop

# put tinytask2w and echokeys1 into PATH !

case "$1" in
-)	# assume 2 test windows were already started
	true;;
*)	# start 2 test windows
	# use mintty version with compiled-in debug code
	#./mintty -Rp -o Y=50 -p left > .minpid1 &
	#./mintty -Rp -o Y=50 -p right > .minpid2 &
	# use mintty with separate debug program
	mintty -p left -Rp -o Y=50 echokeys1 > .minpid1 &
	mintty -p right -Rp -o Y=50 echokeys1 > .minpid2 &
	;;
esac


sleep 2
p1=`tail -1 .minpid1`
p2=`tail -1 .minpid2`
echo checking $p1 $p2

rm -f .minstop
#while ps -p $p1 > /dev/null && ps -p $p2 > /dev/null
#while ! [ -f .minstop ]
while ps -p $p1 > /dev/null && ps -p $p2 > /dev/null && ! [ -f .minstop ]
do	# run precompiled TinyTask script to switch the 2 test windows
	tinytask2w
done

if [ -f .minstop ]
then	cat .minstop
else	echo test window was terminated # e.g. with ^D
fi

Re: Rare character glitch in pty?

[Takashi Yano]

On Wed, 2 Aug 2023 08:32:39 +0200
Thomas Wolff <wrote:
> Am 02.08.2023 um 00:35 schrieb Takashi Yano:
> > On Tue, 1 Aug 2023 23:05:18 +0200
> > Thomas Wolff wrote:
> >> I had reported this to the the main cygwin list:
> >>
> >> Am 20.07.2023 um 08:33 schrieb Thomas Wolff via Cygwin:
> >>> There was a report that on switching terminal windows with the mouse,
> >>> focus event reports (as enabled with ESC[?1004h) would sometimes get
> >>> mangled.
> >>> This is further described in issue reports to mintty/wsltty
> >>> (https://github.com/mintty/wsltty/issues/335) and also to tmux
> >>> (https://github.com/tmux/tmux/issues/3601).
> >>>
> >>> I could reproduce the issue without either of tmux or WSL. However, it
> >>> happens only once in a few hundred instances:
> >>> The escape sequence is changed so that the initial ESC is replaced by
> >>> one of the two subsequent characters, so instead of ESC[O, either of
> >>> [[O or sometimes O[O would be sent to the foreground application.
> >>>
> >>> I traced the issue down to the pty that connects mintty and its client
> >>> application, verified that the correct sequence is passed into write()
> >>> at the pty and the mangled sequence appears at read() in the client
> >>> process. In addition to a minimised test program that behaves like
> >>> `cat -v`, I also also put the test output directly into the client
> >>> process within the mintty code.
> >>> This leaves the only conclusion that the issue must be happening
> >>> somehow within pty handling, maybe in the context of some timing
> >>> condition or Windows messages being passed to mintty.
> >>> Anyhow, I was about to prepare testing with older mintty versions, in
> >>> case I overlooked something, when the OP reported that the issue does
> >>> not happen with cygwin 3.2.0.
> >>> Is there any recent change that could possibly cause such weird
> >>> behaviour?
> >>> Thomas
> >>>
> >> I have now automated the test case to chase the issue and associate it
> >> with a cygwin version. As unlikely as it may appear, results suggest
> >> that there is a case within the pty handling that may change sequences
> >> sent through it once in a while, more likely on a system under heavy load.
> >> I took some of the latest cygwin snapshots (by the way, there are no
> >> newer ones on the snapshots page):
> >> I can reproduce the issue with
> >>       3.3.5-341.x86_64.snap 2022-02-17 11:53 UTC
> >> while it did not occur with
> >>       3.4.0-341.x86_64.snap 2022-01-27 14:34 UTC
> >> Weird enough, the failing newer one is a cygwin 3.3.5 although the older
> >> one is a 3.4.0 version.
> > Can you provide the automated test case? I would like to
> > investigate what is happning.
> 
> Manual test case:
> 1. Run `mintty echokey1` with the attached test program that runs like 
> `cat -v` and detects the glitch
> 2. Run a second test window, same setup to increase the hit rate
> 3. Switch these 2 windows by clicking them in change a few hundred 
> times, until the test program outputs "FAIL"

Thanks for the test case. The manual test case did not output "FAIL"
while 500 forcus-chages in my environment (cygwin 3.4.7).

> Automated test case:
> 1. Use the tool TinyTask (https://www.tinytask.net/) to save the 
> clicking. Sorry, I didn't manage to replace this with a self-made click 
> simulator.
> 2. Place the 2 test windows in a specific position (e.g. covering the 
> two screen halves in a top position)
> 3. Use the Record function of the tool and click to switch windows a 
> dozen times, stop recording
> 4. Save the sequence as a TinyTask script, or use mine (2w.rec 
> attached), better: load the script (Open), then create a standalone test 
> executable (button "exe") to create tinytask2w.exe (I can send that to 
> you if you like)
> 5. Optionally, create some background load on your system
> 6. Minimize other windows in case the test script does not hit the test 
> windows
> 7. Run the test script minptytest (attached) to start the 2 windows and 
> run the TinyTask standalone test in a loop; the script detects a marker 
> file created by the test program; it also detect premature termination 
> of a window (e.g. by hitting ^D in it)

I will try automated test case next for longer test time.


-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: Rare character glitch in pty?

[Takashi Yano]

Hi Thomas,

On Wed, 2 Aug 2023 17:00:43 +0900
Takashi Yano wrote:
> On Wed, 2 Aug 2023 08:32:39 +0200
> Thomas Wolff <wrote:
> > Am 02.08.2023 um 00:35 schrieb Takashi Yano:
> > > On Tue, 1 Aug 2023 23:05:18 +0200
> > > Thomas Wolff wrote:
> > >> I had reported this to the the main cygwin list:
> > >>
> > >> Am 20.07.2023 um 08:33 schrieb Thomas Wolff via Cygwin:
> > >>> There was a report that on switching terminal windows with the mouse,
> > >>> focus event reports (as enabled with ESC[?1004h) would sometimes get
> > >>> mangled.
> > >>> This is further described in issue reports to mintty/wsltty
> > >>> (https://github.com/mintty/wsltty/issues/335) and also to tmux
> > >>> (https://github.com/tmux/tmux/issues/3601).
> > >>>
> > >>> I could reproduce the issue without either of tmux or WSL. However, it
> > >>> happens only once in a few hundred instances:
> > >>> The escape sequence is changed so that the initial ESC is replaced by
> > >>> one of the two subsequent characters, so instead of ESC[O, either of
> > >>> [[O or sometimes O[O would be sent to the foreground application.
> > >>>
> > >>> I traced the issue down to the pty that connects mintty and its client
> > >>> application, verified that the correct sequence is passed into write()
> > >>> at the pty and the mangled sequence appears at read() in the client
> > >>> process. In addition to a minimised test program that behaves like
> > >>> `cat -v`, I also also put the test output directly into the client
> > >>> process within the mintty code.
> > >>> This leaves the only conclusion that the issue must be happening
> > >>> somehow within pty handling, maybe in the context of some timing
> > >>> condition or Windows messages being passed to mintty.
> > >>> Anyhow, I was about to prepare testing with older mintty versions, in
> > >>> case I overlooked something, when the OP reported that the issue does
> > >>> not happen with cygwin 3.2.0.
> > >>> Is there any recent change that could possibly cause such weird
> > >>> behaviour?
> > >>> Thomas
> > >>>
> > >> I have now automated the test case to chase the issue and associate it
> > >> with a cygwin version. As unlikely as it may appear, results suggest
> > >> that there is a case within the pty handling that may change sequences
> > >> sent through it once in a while, more likely on a system under heavy load.
> > >> I took some of the latest cygwin snapshots (by the way, there are no
> > >> newer ones on the snapshots page):
> > >> I can reproduce the issue with
> > >>       3.3.5-341.x86_64.snap 2022-02-17 11:53 UTC
> > >> while it did not occur with
> > >>       3.4.0-341.x86_64.snap 2022-01-27 14:34 UTC
> > >> Weird enough, the failing newer one is a cygwin 3.3.5 although the older
> > >> one is a 3.4.0 version.
> > > Can you provide the automated test case? I would like to
> > > investigate what is happning.
> > 
> > Manual test case:
> > 1. Run `mintty echokey1` with the attached test program that runs like 
> > `cat -v` and detects the glitch
> > 2. Run a second test window, same setup to increase the hit rate
> > 3. Switch these 2 windows by clicking them in change a few hundred 
> > times, until the test program outputs "FAIL"
> 
> Thanks for the test case. The manual test case did not output "FAIL"
> while 500 forcus-chages in my environment (cygwin 3.4.7).
> 
> > Automated test case:
> > 1. Use the tool TinyTask (https://www.tinytask.net/) to save the 
> > clicking. Sorry, I didn't manage to replace this with a self-made click 
> > simulator.
> > 2. Place the 2 test windows in a specific position (e.g. covering the 
> > two screen halves in a top position)
> > 3. Use the Record function of the tool and click to switch windows a 
> > dozen times, stop recording
> > 4. Save the sequence as a TinyTask script, or use mine (2w.rec 
> > attached), better: load the script (Open), then create a standalone test 
> > executable (button "exe") to create tinytask2w.exe (I can send that to 
> > you if you like)
> > 5. Optionally, create some background load on your system
> > 6. Minimize other windows in case the test script does not hit the test 
> > windows
> > 7. Run the test script minptytest (attached) to start the 2 windows and 
> > run the TinyTask standalone test in a loop; the script detects a marker 
> > file created by the test program; it also detect premature termination 
> > of a window (e.g. by hitting ^D in it)
> 
> I will try automated test case next for longer test time.

The issue did not happen for about three hours with your
automated test case in my environment.

I beleave you mean it happens even with cygwin 3.4.7 in your
environment. Right?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: Rare character glitch in pty?

[Takashi Yano]

Hi Thomas,

On Wed, 2 Aug 2023 08:32:39 +0200
Thomas Wolff wrote:
> Am 02.08.2023 um 00:35 schrieb Takashi Yano:
> > On Tue, 1 Aug 2023 23:05:18 +0200
> > Thomas Wolff wrote:
> >> I had reported this to the the main cygwin list:
> >>
> >> Am 20.07.2023 um 08:33 schrieb Thomas Wolff via Cygwin:
> >>> There was a report that on switching terminal windows with the mouse,
> >>> focus event reports (as enabled with ESC[?1004h) would sometimes get
> >>> mangled.
> >>> This is further described in issue reports to mintty/wsltty
> >>> (https://github.com/mintty/wsltty/issues/335) and also to tmux
> >>> (https://github.com/tmux/tmux/issues/3601).
> >>>
> >>> I could reproduce the issue without either of tmux or WSL. However, it
> >>> happens only once in a few hundred instances:
> >>> The escape sequence is changed so that the initial ESC is replaced by
> >>> one of the two subsequent characters, so instead of ESC[O, either of
> >>> [[O or sometimes O[O would be sent to the foreground application.
> >>>
> >>> I traced the issue down to the pty that connects mintty and its client
> >>> application, verified that the correct sequence is passed into write()
> >>> at the pty and the mangled sequence appears at read() in the client
> >>> process. In addition to a minimised test program that behaves like
> >>> `cat -v`, I also also put the test output directly into the client
> >>> process within the mintty code.
> >>> This leaves the only conclusion that the issue must be happening
> >>> somehow within pty handling, maybe in the context of some timing
> >>> condition or Windows messages being passed to mintty.
> >>> Anyhow, I was about to prepare testing with older mintty versions, in
> >>> case I overlooked something, when the OP reported that the issue does
> >>> not happen with cygwin 3.2.0.
> >>> Is there any recent change that could possibly cause such weird
> >>> behaviour?
> >>> Thomas
> >>>
> >> I have now automated the test case to chase the issue and associate it
> >> with a cygwin version. As unlikely as it may appear, results suggest
> >> that there is a case within the pty handling that may change sequences
> >> sent through it once in a while, more likely on a system under heavy load.
> >> I took some of the latest cygwin snapshots (by the way, there are no
> >> newer ones on the snapshots page):
> >> I can reproduce the issue with
> >>       3.3.5-341.x86_64.snap 2022-02-17 11:53 UTC
> >> while it did not occur with
> >>       3.4.0-341.x86_64.snap 2022-01-27 14:34 UTC
> >> Weird enough, the failing newer one is a cygwin 3.3.5 although the older
> >> one is a 3.4.0 version.
> > Can you provide the automated test case? I would like to
> > investigate what is happning.
> 
> Manual test case:
> 1. Run `mintty echokey1` with the attached test program that runs like 
> `cat -v` and detects the glitch
> 2. Run a second test window, same setup to increase the hit rate
> 3. Switch these 2 windows by clicking them in change a few hundred 
> times, until the test program outputs "FAIL"
> 
> Automated test case:
> 1. Use the tool TinyTask (https://www.tinytask.net/) to save the 
> clicking. Sorry, I didn't manage to replace this with a self-made click 
> simulator.
> 2. Place the 2 test windows in a specific position (e.g. covering the 
> two screen halves in a top position)
> 3. Use the Record function of the tool and click to switch windows a 
> dozen times, stop recording
> 4. Save the sequence as a TinyTask script, or use mine (2w.rec 
> attached), better: load the script (Open), then create a standalone test 
> executable (button "exe") to create tinytask2w.exe (I can send that to 
> you if you like)
> 5. Optionally, create some background load on your system
> 6. Minimize other windows in case the test script does not hit the test 
> windows
> 7. Run the test script minptytest (attached) to start the 2 windows and 
> run the TinyTask standalone test in a loop; the script detects a marker 
> file created by the test program; it also detect premature termination 
> of a window (e.g. by hitting ^D in it)

Thanks for the test case. I could reproduce the issue using
the automated test case.

I looked into this problem, and found the cause.

Previously, though readahead buffer handling in pty master was not
fully thread-safe, accept_input() was called from peek_pipe() thread
in select.cc.

The mechanism of the problem is:
1) accept_input() which is called from peek_pipe() thread calls
   eat_readahead(-1) before reading readahead buffer. This allows
   writing to the readahead buffer from another (main) thread.
2) The main thread calls fhandler_pty_master::write() just after
   eat_readahead(-1) was called and before reading the readahead
   buffer by accept_input() called from peek_pipe() thread. This
   overwrites the readahead buffer.
3) The read result from readahead buffer which was overwritten is
   sent to the slave.

This issue has existed this decade.

I'll submit a patch for this issue shortly.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: Rare character glitch in pty?

[Takashi Yano]

On Fri, 4 Aug 2023 17:52:11 +0900
Takashi Yano wrote:
> Hi Thomas,
> 
> On Wed, 2 Aug 2023 08:32:39 +0200
> Thomas Wolff wrote:
> > Am 02.08.2023 um 00:35 schrieb Takashi Yano:
> > > On Tue, 1 Aug 2023 23:05:18 +0200
> > > Thomas Wolff wrote:
> > >> I had reported this to the the main cygwin list:
> > >>
> > >> Am 20.07.2023 um 08:33 schrieb Thomas Wolff via Cygwin:
> > >>> There was a report that on switching terminal windows with the mouse,
> > >>> focus event reports (as enabled with ESC[?1004h) would sometimes get
> > >>> mangled.
> > >>> This is further described in issue reports to mintty/wsltty
> > >>> (https://github.com/mintty/wsltty/issues/335) and also to tmux
> > >>> (https://github.com/tmux/tmux/issues/3601).
> > >>>
> > >>> I could reproduce the issue without either of tmux or WSL. However, it
> > >>> happens only once in a few hundred instances:
> > >>> The escape sequence is changed so that the initial ESC is replaced by
> > >>> one of the two subsequent characters, so instead of ESC[O, either of
> > >>> [[O or sometimes O[O would be sent to the foreground application.
> > >>>
> > >>> I traced the issue down to the pty that connects mintty and its client
> > >>> application, verified that the correct sequence is passed into write()
> > >>> at the pty and the mangled sequence appears at read() in the client
> > >>> process. In addition to a minimised test program that behaves like
> > >>> `cat -v`, I also also put the test output directly into the client
> > >>> process within the mintty code.
> > >>> This leaves the only conclusion that the issue must be happening
> > >>> somehow within pty handling, maybe in the context of some timing
> > >>> condition or Windows messages being passed to mintty.
> > >>> Anyhow, I was about to prepare testing with older mintty versions, in
> > >>> case I overlooked something, when the OP reported that the issue does
> > >>> not happen with cygwin 3.2.0.
> > >>> Is there any recent change that could possibly cause such weird
> > >>> behaviour?
> > >>> Thomas
> > >>>
> > >> I have now automated the test case to chase the issue and associate it
> > >> with a cygwin version. As unlikely as it may appear, results suggest
> > >> that there is a case within the pty handling that may change sequences
> > >> sent through it once in a while, more likely on a system under heavy load.
> > >> I took some of the latest cygwin snapshots (by the way, there are no
> > >> newer ones on the snapshots page):
> > >> I can reproduce the issue with
> > >>       3.3.5-341.x86_64.snap 2022-02-17 11:53 UTC
> > >> while it did not occur with
> > >>       3.4.0-341.x86_64.snap 2022-01-27 14:34 UTC
> > >> Weird enough, the failing newer one is a cygwin 3.3.5 although the older
> > >> one is a 3.4.0 version.
> > > Can you provide the automated test case? I would like to
> > > investigate what is happning.
> > 
> > Manual test case:
> > 1. Run `mintty echokey1` with the attached test program that runs like 
> > `cat -v` and detects the glitch
> > 2. Run a second test window, same setup to increase the hit rate
> > 3. Switch these 2 windows by clicking them in change a few hundred 
> > times, until the test program outputs "FAIL"
> > 
> > Automated test case:
> > 1. Use the tool TinyTask (https://www.tinytask.net/) to save the 
> > clicking. Sorry, I didn't manage to replace this with a self-made click 
> > simulator.
> > 2. Place the 2 test windows in a specific position (e.g. covering the 
> > two screen halves in a top position)
> > 3. Use the Record function of the tool and click to switch windows a 
> > dozen times, stop recording
> > 4. Save the sequence as a TinyTask script, or use mine (2w.rec 
> > attached), better: load the script (Open), then create a standalone test 
> > executable (button "exe") to create tinytask2w.exe (I can send that to 
> > you if you like)
> > 5. Optionally, create some background load on your system
> > 6. Minimize other windows in case the test script does not hit the test 
> > windows
> > 7. Run the test script minptytest (attached) to start the 2 windows and 
> > run the TinyTask standalone test in a loop; the script detects a marker 
> > file created by the test program; it also detect premature termination 
> > of a window (e.g. by hitting ^D in it)
> 
> Thanks for the test case. I could reproduce the issue using
> the automated test case.
> 
> I looked into this problem, and found the cause.
> 
> Previously, though readahead buffer handling in pty master was not
> fully thread-safe, accept_input() was called from peek_pipe() thread
> in select.cc.
> 
> The mechanism of the problem is:
> 1) accept_input() which is called from peek_pipe() thread calls
>    eat_readahead(-1) before reading readahead buffer. This allows
>    writing to the readahead buffer from another (main) thread.
> 2) The main thread calls fhandler_pty_master::write() just after
>    eat_readahead(-1) was called and before reading the readahead
>    buffer by accept_input() called from peek_pipe() thread. This
>    overwrites the readahead buffer.
> 3) The read result from readahead buffer which was overwritten is
>    sent to the slave.
> 
> This issue has existed this decade.
> 
> I'll submit a patch for this issue shortly.

Now, cygwin-3.5.0-0.370.g3b4f6217c371 (Test) is ready.
Please test.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: Rare character glitch in pty?

[Thomas Wolff]

Am 04.08.2023 um 13:33 schrieb Takashi Yano:
> On Fri, 4 Aug 2023 17:52:11 +0900
> Takashi Yano wrote:
>> Hi Thomas,
>>
>> On Wed, 2 Aug 2023 08:32:39 +0200
>> Thomas Wolff wrote:
>>> Am 02.08.2023 um 00:35 schrieb Takashi Yano:
>>>> On Tue, 1 Aug 2023 23:05:18 +0200
>>>> Thomas Wolff wrote:
>>>>> I had reported this to the the main cygwin list:
>>>>>
>>>>> Am 20.07.2023 um 08:33 schrieb Thomas Wolff via Cygwin:
>>>>>> There was a report that on switching terminal windows with the mouse,
>>>>>> focus event reports (as enabled with ESC[?1004h) would sometimes get
>>>>>> mangled.
>>>>>> This is further described in issue reports to mintty/wsltty
>>>>>> (https://github.com/mintty/wsltty/issues/335) and also to tmux
>>>>>> (https://github.com/tmux/tmux/issues/3601).
>>>>>>
>>>>>> I could reproduce the issue without either of tmux or WSL. However, it
>>>>>> happens only once in a few hundred instances:
>>>>>> The escape sequence is changed so that the initial ESC is replaced by
>>>>>> one of the two subsequent characters, so instead of ESC[O, either of
>>>>>> [[O or sometimes O[O would be sent to the foreground application.
>>>>>>
>>>>>> I traced the issue down to the pty that connects mintty and its client
>>>>>> application, verified that the correct sequence is passed into write()
>>>>>> at the pty and the mangled sequence appears at read() in the client
>>>>>> process. In addition to a minimised test program that behaves like
>>>>>> `cat -v`, I also also put the test output directly into the client
>>>>>> process within the mintty code.
>>>>>> This leaves the only conclusion that the issue must be happening
>>>>>> somehow within pty handling, maybe in the context of some timing
>>>>>> condition or Windows messages being passed to mintty.
>>>>>> Anyhow, I was about to prepare testing with older mintty versions, in
>>>>>> case I overlooked something, when the OP reported that the issue does
>>>>>> not happen with cygwin 3.2.0.
>>>>>> Is there any recent change that could possibly cause such weird
>>>>>> behaviour?
>>>>>> Thomas
>>>>>>
>>>>> I have now automated the test case to chase the issue and associate it
>>>>> with a cygwin version. As unlikely as it may appear, results suggest
>>>>> that there is a case within the pty handling that may change sequences
>>>>> sent through it once in a while, more likely on a system under heavy load.
>>>>> I took some of the latest cygwin snapshots (by the way, there are no
>>>>> newer ones on the snapshots page):
>>>>> I can reproduce the issue with
>>>>>        3.3.5-341.x86_64.snap 2022-02-17 11:53 UTC
>>>>> while it did not occur with
>>>>>        3.4.0-341.x86_64.snap 2022-01-27 14:34 UTC
>>>>> Weird enough, the failing newer one is a cygwin 3.3.5 although the older
>>>>> one is a 3.4.0 version.
>>>> Can you provide the automated test case? I would like to
>>>> investigate what is happning.
>>> Manual test case:
>>> 1. Run `mintty echokey1` with the attached test program that runs like
>>> `cat -v` and detects the glitch
>>> 2. Run a second test window, same setup to increase the hit rate
>>> 3. Switch these 2 windows by clicking them in change a few hundred
>>> times, until the test program outputs "FAIL"
>>>
>>> Automated test case:
>>> 1. Use the tool TinyTask (https://www.tinytask.net/) to save the
>>> clicking. Sorry, I didn't manage to replace this with a self-made click
>>> simulator.
>>> 2. Place the 2 test windows in a specific position (e.g. covering the
>>> two screen halves in a top position)
>>> 3. Use the Record function of the tool and click to switch windows a
>>> dozen times, stop recording
>>> 4. Save the sequence as a TinyTask script, or use mine (2w.rec
>>> attached), better: load the script (Open), then create a standalone test
>>> executable (button "exe") to create tinytask2w.exe (I can send that to
>>> you if you like)
>>> 5. Optionally, create some background load on your system
>>> 6. Minimize other windows in case the test script does not hit the test
>>> windows
>>> 7. Run the test script minptytest (attached) to start the 2 windows and
>>> run the TinyTask standalone test in a loop; the script detects a marker
>>> file created by the test program; it also detect premature termination
>>> of a window (e.g. by hitting ^D in it)
>> Thanks for the test case. I could reproduce the issue using
>> the automated test case.
>>
>> I looked into this problem, and found the cause.
>>
>> Previously, though readahead buffer handling in pty master was not
>> fully thread-safe, accept_input() was called from peek_pipe() thread
>> in select.cc.
>>
>> The mechanism of the problem is:
>> 1) accept_input() which is called from peek_pipe() thread calls
>>     eat_readahead(-1) before reading readahead buffer. This allows
>>     writing to the readahead buffer from another (main) thread.
>> 2) The main thread calls fhandler_pty_master::write() just after
>>     eat_readahead(-1) was called and before reading the readahead
>>     buffer by accept_input() called from peek_pipe() thread. This
>>     overwrites the readahead buffer.
>> 3) The read result from readahead buffer which was overwritten is
>>     sent to the slave.
>>
>> This issue has existed this decade.
>>
>> I'll submit a patch for this issue shortly.
> Now, cygwin-3.5.0-0.370.g3b4f6217c371 (Test) is ready.
> Please test.
Great! Thank you for fixing such a subtle issue in a core component.
Any chance to get this back-ported to 3.4.7 (as the last version to 
support ... whatever)?
Thomas

Re: Rare character glitch in pty?

[Takashi Yano]

On Sat, 5 Aug 2023 09:53:30 +0200
Thomas Wolff wrote:
> Am 04.08.2023 um 13:33 schrieb Takashi Yano:
> > On Fri, 4 Aug 2023 17:52:11 +0900
> > Takashi Yano wrote:
> >> Hi Thomas,
> >>
> >> On Wed, 2 Aug 2023 08:32:39 +0200
> >> Thomas Wolff wrote:
> >>> Am 02.08.2023 um 00:35 schrieb Takashi Yano:
> >>>> On Tue, 1 Aug 2023 23:05:18 +0200
> >>>> Thomas Wolff wrote:
> >>>>> I had reported this to the the main cygwin list:
> >>>>>
> >>>>> Am 20.07.2023 um 08:33 schrieb Thomas Wolff via Cygwin:
> >>>>>> There was a report that on switching terminal windows with the mouse,
> >>>>>> focus event reports (as enabled with ESC[?1004h) would sometimes get
> >>>>>> mangled.
> >>>>>> This is further described in issue reports to mintty/wsltty
> >>>>>> (https://github.com/mintty/wsltty/issues/335) and also to tmux
> >>>>>> (https://github.com/tmux/tmux/issues/3601).
> >>>>>>
> >>>>>> I could reproduce the issue without either of tmux or WSL. However, it
> >>>>>> happens only once in a few hundred instances:
> >>>>>> The escape sequence is changed so that the initial ESC is replaced by
> >>>>>> one of the two subsequent characters, so instead of ESC[O, either of
> >>>>>> [[O or sometimes O[O would be sent to the foreground application.
> >>>>>>
> >>>>>> I traced the issue down to the pty that connects mintty and its client
> >>>>>> application, verified that the correct sequence is passed into write()
> >>>>>> at the pty and the mangled sequence appears at read() in the client
> >>>>>> process. In addition to a minimised test program that behaves like
> >>>>>> `cat -v`, I also also put the test output directly into the client
> >>>>>> process within the mintty code.
> >>>>>> This leaves the only conclusion that the issue must be happening
> >>>>>> somehow within pty handling, maybe in the context of some timing
> >>>>>> condition or Windows messages being passed to mintty.
> >>>>>> Anyhow, I was about to prepare testing with older mintty versions, in
> >>>>>> case I overlooked something, when the OP reported that the issue does
> >>>>>> not happen with cygwin 3.2.0.
> >>>>>> Is there any recent change that could possibly cause such weird
> >>>>>> behaviour?
> >>>>>> Thomas
> >>>>>>
> >>>>> I have now automated the test case to chase the issue and associate it
> >>>>> with a cygwin version. As unlikely as it may appear, results suggest
> >>>>> that there is a case within the pty handling that may change sequences
> >>>>> sent through it once in a while, more likely on a system under heavy load.
> >>>>> I took some of the latest cygwin snapshots (by the way, there are no
> >>>>> newer ones on the snapshots page):
> >>>>> I can reproduce the issue with
> >>>>>        3.3.5-341.x86_64.snap 2022-02-17 11:53 UTC
> >>>>> while it did not occur with
> >>>>>        3.4.0-341.x86_64.snap 2022-01-27 14:34 UTC
> >>>>> Weird enough, the failing newer one is a cygwin 3.3.5 although the older
> >>>>> one is a 3.4.0 version.
> >>>> Can you provide the automated test case? I would like to
> >>>> investigate what is happning.
> >>> Manual test case:
> >>> 1. Run `mintty echokey1` with the attached test program that runs like
> >>> `cat -v` and detects the glitch
> >>> 2. Run a second test window, same setup to increase the hit rate
> >>> 3. Switch these 2 windows by clicking them in change a few hundred
> >>> times, until the test program outputs "FAIL"
> >>>
> >>> Automated test case:
> >>> 1. Use the tool TinyTask (https://www.tinytask.net/) to save the
> >>> clicking. Sorry, I didn't manage to replace this with a self-made click
> >>> simulator.
> >>> 2. Place the 2 test windows in a specific position (e.g. covering the
> >>> two screen halves in a top position)
> >>> 3. Use the Record function of the tool and click to switch windows a
> >>> dozen times, stop recording
> >>> 4. Save the sequence as a TinyTask script, or use mine (2w.rec
> >>> attached), better: load the script (Open), then create a standalone test
> >>> executable (button "exe") to create tinytask2w.exe (I can send that to
> >>> you if you like)
> >>> 5. Optionally, create some background load on your system
> >>> 6. Minimize other windows in case the test script does not hit the test
> >>> windows
> >>> 7. Run the test script minptytest (attached) to start the 2 windows and
> >>> run the TinyTask standalone test in a loop; the script detects a marker
> >>> file created by the test program; it also detect premature termination
> >>> of a window (e.g. by hitting ^D in it)
> >> Thanks for the test case. I could reproduce the issue using
> >> the automated test case.
> >>
> >> I looked into this problem, and found the cause.
> >>
> >> Previously, though readahead buffer handling in pty master was not
> >> fully thread-safe, accept_input() was called from peek_pipe() thread
> >> in select.cc.
> >>
> >> The mechanism of the problem is:
> >> 1) accept_input() which is called from peek_pipe() thread calls
> >>     eat_readahead(-1) before reading readahead buffer. This allows
> >>     writing to the readahead buffer from another (main) thread.
> >> 2) The main thread calls fhandler_pty_master::write() just after
> >>     eat_readahead(-1) was called and before reading the readahead
> >>     buffer by accept_input() called from peek_pipe() thread. This
> >>     overwrites the readahead buffer.
> >> 3) The read result from readahead buffer which was overwritten is
> >>     sent to the slave.
> >>
> >> This issue has existed this decade.
> >>
> >> I'll submit a patch for this issue shortly.
> > Now, cygwin-3.5.0-0.370.g3b4f6217c371 (Test) is ready.
> > Please test.
> Great! Thank you for fixing such a subtle issue in a core component.
> Any chance to get this back-ported to 3.4.7 (as the last version to 
> support ... whatever)?

I hope 3.4.8 would be released before 3.5.0. Cygwin 3.4.7 has
another big issue:
https://sourceware.org/pipermail/newlib/2023/020443.html
so, I am not happy if 3.4.7 is the final cygwin-3_4-branch
release.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: Rare character glitch in pty?

[Corinna Vinschen]

On Aug  5 17:10, Takashi Yano wrote:
> On Sat, 5 Aug 2023 09:53:30 +0200
> Thomas Wolff wrote:
> > Great! Thank you for fixing such a subtle issue in a core component.
> > Any chance to get this back-ported to 3.4.7 (as the last version to 
> > support ... whatever)?
> 
> I hope 3.4.8 would be released before 3.5.0. Cygwin 3.4.7 has
> another big issue:
> https://sourceware.org/pipermail/newlib/2023/020443.html
> so, I am not happy if 3.4.7 is the final cygwin-3_4-branch
> release.

We certainly do a 3.4.8 and probably more 3.4 versions before 3.5.

I still didn't have a good clue how to add collating symbols and
equivalence class expressions to regex and I would hate to push
out a 3.5 version with support for that in fnmatch and glob, but
not in regex.


Corinna

Re: Rare character glitch in pty?

[Takashi Yano]

On Mon, 7 Aug 2023 10:28:16 +0200
Corinna Vinschen wrote:
> On Aug  5 17:10, Takashi Yano wrote:
> > On Sat, 5 Aug 2023 09:53:30 +0200
> > Thomas Wolff wrote:
> > > Great! Thank you for fixing such a subtle issue in a core component.
> > > Any chance to get this back-ported to 3.4.7 (as the last version to 
> > > support ... whatever)?
> > 
> > I hope 3.4.8 would be released before 3.5.0. Cygwin 3.4.7 has
> > another big issue:
> > https://sourceware.org/pipermail/newlib/2023/020443.html
> > so, I am not happy if 3.4.7 is the final cygwin-3_4-branch
> > release.
> 
> We certainly do a 3.4.8 and probably more 3.4 versions before 3.5.

I was relieved to hear that. Thanks!

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>