less.exe often hangs inside tmux as Git's pager when quitting and immediately typing something
#4812
Comments
|
I'm now trying to reproduce the problem, however, I cannot so far. |
This is weird. One is real process and the other seems to be a stub process. However, if the |
|
@tyan0 thank you for having a look!
Yes, I am positive that it is the MSYS2 version of $ ldd /usr/bin/less.exe
ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffe24710000)
KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffe23650000)
KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffe21bc0000)
msys-ncursesw6.dll => /usr/bin/msys-ncursesw6.dll (0x5fcb10000)
msys-pcre2-8-0.dll => /usr/bin/msys-pcre2-8-0.dll (0x5d1c20000)
msys-2.0.dll => /usr/bin/msys-2.0.dll (0x210040000)
Here goes: $ ps -W | grep less
I 17209 1 17209 39580 cons1 4096 13:28:14 /usr/bin/less
$ wmic process where processid=39580 get commandline,parentprocessid,processid
CommandLine ParentProcessId ProcessId
less 43832 39580
$ wmic process where processid=43832 get commandline,parentprocessid,processid
CommandLine ParentProcessId ProcessId
git branch --sort=-committerdate -l 37056 43832
$ wmic process where processid=37056 get commandline,parentprocessid,processid
CommandLine ParentProcessId ProcessId
C:\git-sdk-64\mingw64\bin\git.exe list-branches 29792 37056
$ wmic process where processid=29792 get commandline,parentprocessid,processid
CommandLine ParentProcessId ProcessId
C:\git-sdk-64\usr\bin\bash.exe 15836 29792
$ wmic process where processid=15836 get commandline,parentprocessid,processid
CommandLine ParentProcessId ProcessId
C:\git-sdk-64\usr\bin\bash.exe 14100 15836
$ wmic process where processid=14100 get commandline,parentprocessid,processid
No Instance(s) Available.
$ ps -W | grep -e 43832 -e 37056 -e 29792 -e 15836 -e 39580
1446 1231 1446 15836 pty5 4096 Feb 11 /usr/bin/bash
95328 0 0 29792 ? 0 13:28:14 C:\git-sdk-64\usr\bin\bash.exe
17208 1446 17208 37056 pty5 4096 13:28:13 /mingw64/bin/git
109368 0 0 43832 ? 0 13:28:14 C:\git-sdk-64\mingw64\libexec\git-core\git.exe
I 17209 1 17209 39580 cons1 4096 13:28:14 /usr/bin/lessI should probably mention that I still run with One thing I just noticed is that |
|
Thanks for the additional information. I still fail to reproduce the issue both with and without pseudo console.
In this case, only one
This occurs only when pseudo console is enabled. If it is disabled, both |
|
The stack trace looks like a normal |
|
Could you please take a log using attached patch? for_dscho_log.patch Steps(1) Apply the patch and build runtime. After all, please send me the copied log file. Thanks in advance. |
|
The log patch revised. Please use this new one. [Edited] |
|
Thank you @tyan0. I asked GitHub Actions to build the artifact over here: https://github.com/dscho/msys2-runtime/actions/runs/7923333552/job/21632838417. |
|
Please also apply this additional patch. Is the issue still not logged? |
Thank you! Force-pushed and building.
I have not had much time to work in my Git for Windows SDK, therefore the issue has not happened again yet. But it is logged, the log file is already ~64kB and growing, eagerly awaiting a hang. As soon as the build is finished, I will replace the MSYS2 runtime and continue monitoring. |
Sorry, I missed this comment before. In my case, |
|
FWIW I am now running without |
|
The log taken while no issue happened is not worth enough. You can delete it and renew the logging. Why on the earth the issue cannot be reproduced... |
D'oh, why didn't I think of deleting it ;-)
I think it really might have something to do with the mix of |
|
@dscho you may be interested in msys2/msys2-runtime#185. It’s a bit long, but the summary is that the default A smaller point, but to be aware of, is that while the Git for Windows installer will set As a final note, I had also made the suggestion that msys2 should take from the GFW the feature of having the commit hash in the dll version, so I was glad to see you submitted PR 192 to msys-runtime (even if that is not the main object of the change, it’s a nice bonus side effect). In general, thank you for your hard work! |
|
The problem is that |
@tyan0 FWIW I have not experienced any hang in the meantime, and have just deleted a 6.1G log file to make space for more. |
|
Still no problem, so I'll just call it and say that |
|
@tyan0 it's happening again, but this time I paid close attention to what I did, and it was that I pressed Ctrl+C while |
This is a somewhat special scenario, yet I am worried that it can hit users in many other scenarios, too. The problem seems to be yet another deadlock in the MSYS2/Cygwin runtime.
Repro
Note: This repro is not consistent, it often works, but sometimes does not.
In a
tmuxsession, I rangit diff/git log, which calls (MINGW)git.exethat then spawns (MSYS)less.exe. Then I press Q and immediately after that ⬆️. Now the process hangs. Actually, there are two processes forless, I assume one is the real one and the other one exists only to handle signals? The latter is the one hanging, and it has the following threads:Thread 6 is probably just a side effect of attaching with
gdb. Here are the stacktraces:Stacktrace of thread 1 ("less")
Stacktrace of thread 2 ("sig")
Stacktrace of thread 3 ("consm")
Stacktrace of thread 4 ("conssel")
Stacktrace of thread 5 ("pipesel")
This is with MSYS2 runtime 3.4.10-b7ef037e.x86_64, i.e. built from git-for-windows/msys2-runtime@b7ef037, i.e. there seems to be a deadlock between this
cygwait(40)and thiscygwait(get_handle(), timeout).The text was updated successfully, but these errors were encountered: