-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Address underlying cause of hanging 'git push' for git://-protocol servers without sendpack.sideband=false #2376
Comments
Relevant blog article. Looks like the Win32 API I recommended in #907 could be a good match. Need to verify, though:
|
Switching out plain
Let me tinker around a bit. Unfortunately this means I have to leave the cozy Git SDK environment a bit and switch to VS and WinDbg to tickle out the necessary details. NB: provided the targeted Windows version is properly expressed by means of |
Could you remind me, here, what my question was? |
Which version of Windows is the minimum Git for Windows aims for? It's basically something that the project would define. But I guess the fact that code with |
Currently, the earliest Windows version we support is Vista.
According to https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getfileinformationbyhandleex, this function is supported from Windows Vista on. So we're free to use it, without the need for |
Sorry @dscho I also lost sight of this. Will re-read what you wrote tonight and comment then. |
Any news on this? |
Any news on this? Is it possible to have an environment variable to bypass tty detection? |
Closing as stale. |
Sorry for "not following protocol" with this ticket, but it's a mix of stuff collected from at least three different tickets, notably: #907, #2278 and #2375.
I'd like to use this to track my own findings and progress regarding the underlying issue, which I think is - in my opinion - caused by attempting to use
NtQueryObject
to query the name of the pipes acting as standard handles. Pipes are beasts that are different from Unix pipes on Windows. Most importantly this particular operation (trying to query object information) is known to be blocking under certain circumstances. Especially when the pipes are in a blocking state (default as far as I'm aware).Copying from my comment in #907 ...:
Anyway, regarding the actual topic at hand (blocking inside
git pack-objects
), I think you would be well advised to talk to some of the folks at MS who are much better equipped to provide an answer than I am. As I understand you work (or worked?) for MS to drive this project forward? Anyway, looking atdetect_msys_tty
I can take a guess of what's going on here. The namespaces for both mailslots and (named) pipes are prone to blocking as I have learned many years ago. The only safe method I ever found to work with these was in a separate thread as I frequently ran into issues where operations such as theNtQueryObject
call indetect_msys_tty
blocked. Forntobjx
I didn't go down that route yet, but a predecessor tool had also support for listing mailslots and pipes. If you rely onNtQueryObject
for such a use-case, I think that's questionable (but then, so is the overall enterprise of pretending Windows is unixy enough for all of this ;)). Although by far not as knowledgeable as one Mark Russinovich of Sysinternals/Microsoft fame, I think that I know a thing or two about the NT native API.For the record the two stack traces for the "client" and "server" processes respectively in the case of blocking:
Parent
git
process (git push
):Child
git
process (git pack-objects --all-progress-implied --revs --stdout --thin --delta-base-offset --progress
):I remember having had this problem with pipes myself in the past and I'll try to consult with a friend who also had the very same problem in conjunction with some proprietary software in times of Windows XP. Several publicly available tools, e.g. from Microsoft but also others, dodge this bullet by employing a driver of their own. Not really practical for Git, I'll admit.
Thinking of XP, what's the lowest version of Windows on which Git for Windows is supposed to run? I'm asking because the
GetFileInformationByHandleEx
is supposed to do exactly what theNtQueryObject
function does in this particular case. The olderGetHandleInformation
is related, but doesn't quite cover the use-case. Either way you'll get fewer "🙄" from Windows devs than when using the NT native API function (i.e.NtQueryObject
).The text was updated successfully, but these errors were encountered: