On Wed, 8 Jan 2025 18:05:53 -0800 (PST) Jeremy Drake wrote: > On Thu, 9 Jan 2025, Takashi Yano wrote: > > > On Wed, 8 Jan 2025 16:48:41 +0100 > > Corinna Vinschen wrote: > > > Does this patch fix Bruno's bash issue as well? > > > > I'm not sure because it is not reproducible as he said. > > I also could not reproduce that. > > > > However, at least this fixes the issue that Jeremy encountered: > > https://cygwin.com/pipermail/cygwin/2024-December/256977.html > > > > But, even with this patch, Jeremy reported another hang issue > > that also is not reproducible: > > https://cygwin.com/pipermail/cygwin/2024-December/256987.html > > Yes, this patch helped the hangs I was seeing on Windows on ARM64. > However, there is still some hang issue in 3.5.5 (which occurs on > native x86_64) that is not there in 3.5.4. Git for Windows' test suite > seems to be somewhat reliable at triggering this, but it's hardly a > minimal test case ;). > > Because of this issue, MSYS2 has been keeping 3.5.5 in its 'staging' state > (rather than deploying it to normal users), and Git for Windows rolled > back to 3.5.4 before the release of the latest Git RC.
I might have successfully reproduced this issue. I tried building cygwin1.dll repeatedly for some of my machines, and one of them hung in fhandler_pipe::raw_read() as lazka's case: https://github.com/msys2/msys2-runtime/pull/251#issuecomment-2571338429 The call: L358: waitret = cygwait (select_sem, select_sem_timeout); never returned even with select_sem_timeout == 1 until a signal (such as SIGTERM, SIGKILL) arrives. In this situation, attaching gdb to the process hanging and issuing 'si' command do not return. Something (stack?) seems to be completely broken. I'll try to bisect which commit causes this issue. Please wait a while. -- Takashi Yano <takashi.y...@nifty.ne.jp>
