* Re: Rare character glitch in pty?
[not found] <6f0bfdf8-a557-0540-0367-6846406f941d@towo.net>
@ 2023-08-01 21:05 ` Thomas Wolff
2023-08-01 21:27 ` Corinna Vinschen
2023-08-01 22:35 ` Rare character glitch in pty? Takashi Yano
0 siblings, 2 replies; 24+ messages in thread
From: Thomas Wolff @ 2023-08-01 21:05 UTC (permalink / raw)
To: cygwin-developers
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Rare character glitch in pty?
2023-08-01 21:05 ` Rare character glitch in pty? Thomas Wolff
@ 2023-08-01 21:27 ` Corinna Vinschen
2023-08-02 6:36 ` cygwin build Thomas Wolff
2023-08-01 22:35 ` Rare character glitch in pty? Takashi Yano
1 sibling, 1 reply; 24+ messages in thread
From: Corinna Vinschen @ 2023-08-01 21:27 UTC (permalink / raw)
To: Thomas Wolff; +Cc: cygwin-developers
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Rare character glitch in pty?
2023-08-01 21:05 ` Rare character glitch in pty? Thomas Wolff
2023-08-01 21:27 ` Corinna Vinschen
@ 2023-08-01 22:35 ` Takashi Yano
2023-08-02 6:32 ` Thomas Wolff
1 sibling, 1 reply; 24+ messages in thread
From: Takashi Yano @ 2023-08-01 22:35 UTC (permalink / raw)
To: cygwin-developers
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>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Rare character glitch in pty?
2023-08-01 22:35 ` Rare character glitch in pty? Takashi Yano
@ 2023-08-02 6:32 ` Thomas Wolff
2023-08-02 8:00 ` Takashi Yano
2023-08-04 8:52 ` Takashi Yano
0 siblings, 2 replies; 24+ messages in thread
From: Thomas Wolff @ 2023-08-02 6:32 UTC (permalink / raw)
To: cygwin-developers
[-- 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* cygwin build
2023-08-01 21:27 ` Corinna Vinschen
@ 2023-08-02 6:36 ` Thomas Wolff
2023-08-02 6:42 ` Takashi Yano
` (2 more replies)
0 siblings, 3 replies; 24+ messages in thread
From: Thomas Wolff @ 2023-08-02 6:36 UTC (permalink / raw)
To: cygwin-developers
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: cygwin build
2023-08-02 6:36 ` cygwin build Thomas Wolff
@ 2023-08-02 6:42 ` Takashi Yano
2023-08-02 8:09 ` Corinna Vinschen
2023-08-03 13:13 ` Jon Turney
2 siblings, 0 replies; 24+ messages in thread
From: Takashi Yano @ 2023-08-02 6:42 UTC (permalink / raw)
To: cygwin-developers
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>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Rare character glitch in pty?
2023-08-02 6:32 ` Thomas Wolff
@ 2023-08-02 8:00 ` Takashi Yano
2023-08-02 13:16 ` Takashi Yano
2023-08-04 8:52 ` Takashi Yano
1 sibling, 1 reply; 24+ messages in thread
From: Takashi Yano @ 2023-08-02 8:00 UTC (permalink / raw)
To: cygwin-developers
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>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: cygwin build
2023-08-02 6:36 ` cygwin build Thomas Wolff
2023-08-02 6:42 ` Takashi Yano
@ 2023-08-02 8:09 ` Corinna Vinschen
2023-08-03 8:21 ` Thomas Wolff
2023-08-03 13:13 ` Jon Turney
2 siblings, 1 reply; 24+ messages in thread
From: Corinna Vinschen @ 2023-08-02 8:09 UTC (permalink / raw)
To: Thomas Wolff; +Cc: cygwin-developers
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Rare character glitch in pty?
2023-08-02 8:00 ` Takashi Yano
@ 2023-08-02 13:16 ` Takashi Yano
0 siblings, 0 replies; 24+ messages in thread
From: Takashi Yano @ 2023-08-02 13:16 UTC (permalink / raw)
To: cygwin-developers
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>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: cygwin build
2023-08-02 8:09 ` Corinna Vinschen
@ 2023-08-03 8:21 ` Thomas Wolff
2023-08-03 13:12 ` Jon Turney
0 siblings, 1 reply; 24+ messages in thread
From: Thomas Wolff @ 2023-08-03 8:21 UTC (permalink / raw)
To: cygwin-developers
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: cygwin build
2023-08-03 8:21 ` Thomas Wolff
@ 2023-08-03 13:12 ` Jon Turney
2023-08-05 18:18 ` Thomas Wolff
0 siblings, 1 reply; 24+ messages in thread
From: Jon Turney @ 2023-08-03 13:12 UTC (permalink / raw)
To: Thomas Wolff, cygwin-developers
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: cygwin build
2023-08-02 6:36 ` cygwin build Thomas Wolff
2023-08-02 6:42 ` Takashi Yano
2023-08-02 8:09 ` Corinna Vinschen
@ 2023-08-03 13:13 ` Jon Turney
2 siblings, 0 replies; 24+ messages in thread
From: Jon Turney @ 2023-08-03 13:13 UTC (permalink / raw)
To: Thomas Wolff, cygwin-developers
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)
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Rare character glitch in pty?
2023-08-02 6:32 ` Thomas Wolff
2023-08-02 8:00 ` Takashi Yano
@ 2023-08-04 8:52 ` Takashi Yano
2023-08-04 11:33 ` Takashi Yano
1 sibling, 1 reply; 24+ messages in thread
From: Takashi Yano @ 2023-08-04 8:52 UTC (permalink / raw)
To: cygwin-developers
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>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Rare character glitch in pty?
2023-08-04 8:52 ` Takashi Yano
@ 2023-08-04 11:33 ` Takashi Yano
2023-08-05 7:53 ` Thomas Wolff
0 siblings, 1 reply; 24+ messages in thread
From: Takashi Yano @ 2023-08-04 11:33 UTC (permalink / raw)
To: cygwin-developers
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>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Rare character glitch in pty?
2023-08-04 11:33 ` Takashi Yano
@ 2023-08-05 7:53 ` Thomas Wolff
2023-08-05 8:10 ` Takashi Yano
0 siblings, 1 reply; 24+ messages in thread
From: Thomas Wolff @ 2023-08-05 7:53 UTC (permalink / raw)
To: cygwin-developers
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Rare character glitch in pty?
2023-08-05 7:53 ` Thomas Wolff
@ 2023-08-05 8:10 ` Takashi Yano
2023-08-07 8:28 ` Corinna Vinschen
0 siblings, 1 reply; 24+ messages in thread
From: Takashi Yano @ 2023-08-05 8:10 UTC (permalink / raw)
To: cygwin-developers
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>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: cygwin build
2023-08-03 13:12 ` Jon Turney
@ 2023-08-05 18:18 ` Thomas Wolff
2023-08-05 22:20 ` Takashi Yano
2023-08-06 18:53 ` Jon Turney
0 siblings, 2 replies; 24+ messages in thread
From: Thomas Wolff @ 2023-08-05 18:18 UTC (permalink / raw)
To: Jon Turney, cygwin-developers
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: cygwin build
2023-08-05 18:18 ` Thomas Wolff
@ 2023-08-05 22:20 ` Takashi Yano
2023-08-06 6:51 ` Thomas Wolff
2023-08-06 18:53 ` Jon Turney
1 sibling, 1 reply; 24+ messages in thread
From: Takashi Yano @ 2023-08-05 22:20 UTC (permalink / raw)
To: cygwin-developers
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>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: cygwin build
2023-08-05 22:20 ` Takashi Yano
@ 2023-08-06 6:51 ` Thomas Wolff
0 siblings, 0 replies; 24+ messages in thread
From: Thomas Wolff @ 2023-08-06 6:51 UTC (permalink / raw)
To: cygwin-developers
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: cygwin build
2023-08-05 18:18 ` Thomas Wolff
2023-08-05 22:20 ` Takashi Yano
@ 2023-08-06 18:53 ` Jon Turney
2023-08-07 6:11 ` Thomas Wolff
1 sibling, 1 reply; 24+ messages in thread
From: Jon Turney @ 2023-08-06 18:53 UTC (permalink / raw)
To: cygwin-developers, Thomas Wolff
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: cygwin build
2023-08-06 18:53 ` Jon Turney
@ 2023-08-07 6:11 ` Thomas Wolff
2023-08-07 8:25 ` Corinna Vinschen
0 siblings, 1 reply; 24+ messages in thread
From: Thomas Wolff @ 2023-08-07 6:11 UTC (permalink / raw)
To: Jon Turney, cygwin-developers
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
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: cygwin build
2023-08-07 6:11 ` Thomas Wolff
@ 2023-08-07 8:25 ` Corinna Vinschen
0 siblings, 0 replies; 24+ messages in thread
From: Corinna Vinschen @ 2023-08-07 8:25 UTC (permalink / raw)
To: Thomas Wolff; +Cc: Jon Turney, cygwin-developers
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Rare character glitch in pty?
2023-08-05 8:10 ` Takashi Yano
@ 2023-08-07 8:28 ` Corinna Vinschen
2023-08-07 11:38 ` Takashi Yano
0 siblings, 1 reply; 24+ messages in thread
From: Corinna Vinschen @ 2023-08-07 8:28 UTC (permalink / raw)
To: Takashi Yano; +Cc: cygwin-developers
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Rare character glitch in pty?
2023-08-07 8:28 ` Corinna Vinschen
@ 2023-08-07 11:38 ` Takashi Yano
0 siblings, 0 replies; 24+ messages in thread
From: Takashi Yano @ 2023-08-07 11:38 UTC (permalink / raw)
To: cygwin-developers
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>
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2023-08-07 11:38 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <6f0bfdf8-a557-0540-0367-6846406f941d@towo.net>
2023-08-01 21:05 ` Rare character glitch in pty? Thomas Wolff
2023-08-01 21:27 ` Corinna Vinschen
2023-08-02 6:36 ` cygwin build Thomas Wolff
2023-08-02 6:42 ` Takashi Yano
2023-08-02 8:09 ` Corinna Vinschen
2023-08-03 8:21 ` Thomas Wolff
2023-08-03 13:12 ` Jon Turney
2023-08-05 18:18 ` Thomas Wolff
2023-08-05 22:20 ` Takashi Yano
2023-08-06 6:51 ` Thomas Wolff
2023-08-06 18:53 ` Jon Turney
2023-08-07 6:11 ` Thomas Wolff
2023-08-07 8:25 ` Corinna Vinschen
2023-08-03 13:13 ` Jon Turney
2023-08-01 22:35 ` Rare character glitch in pty? Takashi Yano
2023-08-02 6:32 ` Thomas Wolff
2023-08-02 8:00 ` Takashi Yano
2023-08-02 13:16 ` Takashi Yano
2023-08-04 8:52 ` Takashi Yano
2023-08-04 11:33 ` Takashi Yano
2023-08-05 7:53 ` Thomas Wolff
2023-08-05 8:10 ` Takashi Yano
2023-08-07 8:28 ` Corinna Vinschen
2023-08-07 11:38 ` Takashi Yano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).