Windows 10 - sh.exe fatal error in forked process - MapViewOfFileEx

[voxeohwiegard]

• I was not able to find an open
  or closed issue
  matching what I'm seeing

Setup

• Which version of Git for Windows are you using? 32-bit or 64-bit? Include the
  output of git version as well.

Git-2.9.2-64-bit.exe

$ git --version
 git version 2.9.2.windows.1

• Which version of Windows are you running? 32-bit or 64-bit?

Windows 10 64-bit

• What options did you set as part of the installation? Or did you choose the
  defaults?

Only default options

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

no

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

  CMD

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

1. Open CMD
2. cd into an existing git repository
3. run git pull --rebase

• What did you expect to occur after running these commands?

An updated repository

• What actually happened instead?

C:\sourcecode\repo>git pull --rebase
      0 [main] sh 1340 C:\Program Files\Git\usr\bin\sh.exe: *** fatal error in forked process - MapViewOfFileEx '(null)'(0x24), Win32 error 5.  Terminating.
      0 [main] sh 244 fork: child 1340 - died waiting for dll loading, errno 11
/mingw64/libexec/git-core/git-sh-setup: fork: retry: No child processes

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

Seems to be independent from the repository and happens for all repositories.

[dscho]

I cannot verify that MCVE:

C:\Users\me\my-checkout>git pull --rebase
me@my.host's password:
Current branch master is up to date.

No error.

[dscho]

So it seems you have to dig further on your side. Maybe setting GIT_TRACE=1 before running the command sheds light into the problem?

[kostix]

@voxeohwiegard, does plain git rebase also fail for you?

[voxeohwiegard]

a plain git rebase works fine

[voxeohwiegard]

The requested trace output is

C:\sourcecode\repo>git pull --rebase
14:59:37.543227 git.c:350               trace: built-in: git 'pull' '--rebase'
14:59:37.548232 run-command.c:336       trace: run_command: 'merge-base' '--fork-point' 'refs/remotes/origin/master' 'master'
14:59:37.574250 run-command.c:336       trace: run_command: 'fetch' '--update-head-ok'
14:59:37.590262 git.c:350               trace: built-in: git 'fetch' '--update-head-ok'
14:59:37.592263 run-command.c:336       trace: run_command: 'git-remote-https' 'origin' 'https://user@host/repo.git'
14:59:38.316322 run-command.c:336       trace: run_command: 'git credential-manager get'
14:59:38.366978 git.c:563               trace: exec: 'git-credential-manager' 'get'
14:59:38.366978 run-command.c:336       trace: run_command: 'git-credential-manager' 'get'
14:59:39.950945 run-command.c:336       trace: run_command: 'git credential-manager store'
14:59:39.985282 git.c:563               trace: exec: 'git-credential-manager' 'store'
14:59:39.985282 run-command.c:336       trace: run_command: 'git-credential-manager' 'store'
14:59:40.113371 run-command.c:336       trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet'
14:59:40.135135 run-command.c:336       trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all'
14:59:40.151147 git.c:350               trace: built-in: git 'rev-list' '--objects' '--stdin' '--not' '--all'
14:59:40.165157 run-command.c:964       run_processes_parallel: preparing to run up to 1 tasks
14:59:40.165157 run-command.c:996       run_processes_parallel: done
14:59:40.165157 run-command.c:336       trace: run_command: 'gc' '--auto'
14:59:40.183169 git.c:350               trace: built-in: git 'gc' '--auto'
14:59:40.190173 run-command.c:336       trace: run_command: 'rebase' '--onto' '28a41509e3fd6a00b82045c77e01e0d5c1d616cf' '28a41509e3fd6a00b82045c77e01e0d5c1d616cf'
14:59:40.207186 git.c:563               trace: exec: 'git-rebase' '--onto' '28a41509e3fd6a00b82045c77e01e0d5c1d616cf' '28a41509e3fd6a00b82045c77e01e0d5c1d616cf'
14:59:40.207186 run-command.c:336       trace: run_command: 'git-rebase' '--onto' '28a41509e3fd6a00b82045c77e01e0d5c1d616cf' '28a41509e3fd6a00b82045c77e01e0d5c1d616cf'
      0 [main] sh 3756 C:\Program Files\Git\usr\bin\sh.exe: *** fatal error in forked process - MapViewOfFileEx '(null)'(0x28), Win32 error 5.  Terminating.
      0 [main] sh 3372 fork: child 3756 - died waiting for dll loading, errno 11
/mingw64/libexec/git-core/git-sh-setup: fork: retry: No child processes

[DaveSlinn]

Several PCs in my office are receiving a similar error. We have tried both x64 and x86 versions of git for Windows, v2.9.2. We can recreate by doing a simple git help push command.

We are using 64-bit Windows 10 Enterprise (Version 1511 Build 10586.494)

[simon-p-r]

@GmsDave works fine on my system which is exactly the same Windows 10 version and build number as yours

[alex29ua]

Git commit gives similar VIM error.
fatal error - cygheap base mismatch detected
It says I need to delete other cygwin dlls, though I have only one.

This only happens if I start CMD from my Total Commander. If I run CMD from Win+R, it works fine.

No special settings or PATHs for the Total Commander though.

[fourpastmidnight]

One thing I noticed in the error output above when MapViewOfFileEx is being called is the error it's returning: error 5. This error code normally means Access Denied. Unfortunately, IIRC, this error code can be returned for a variety of issues that may/may not be related to permissions. But since this hasn't been mentioned, I thought it might be worth looking into the documentation for MapViewOfFileEx to see if/when an Access Denied error is returned; and IIRC, the HRESULT should be 0x80040005. From the documentation, it seems that if this method fails, NULL is returned and you can use GetLastError for more detailed error information. Again, in the output above, it appears that MapViewOfFileEx is returning NULL and that GetLasrError is being called, returning 0x80040005, which when translated at the command prompt becomes (Win32|System) error 5. Access is denied.

Is there possibly some program running that's holding a lock on the file(s) in question? Is/Are the file(s) located in a protected location? Or is something trying to be done with whatever file is being memory-mapped in an incorrect (read: unauthorized) manner? I don't have time right now to look into the questions, but I hope this might be useful information.

[DaveSlinn]

@simon-p-r Our dev team consists of 9 PCs - all configured from the same Win 10 image. We have this problem on roughly half of them. The others work fine.

@fourpastmidnight I don't know if this helps, but on those PCs experiencing the error, the git bash shell works fine in launching the man page. It only dies when trying it from the Windows command prompt. We thought it might be a UAC issue on Windows 10, but we compared those PCs that work with those that don't, and their UAC settings are the same. We retried with GIT_TRACE on, as suggested earlier. Here is the result:

[dscho]

@GmsDave this is just a wild shot: could you download https://github.com/git-for-windows/msys2-runtime/releases/download/snapshot-2016-07-09/msys-2.0.dll and drop it into \usr\bin (overwriting the existing msys-2.0.dll) and try again?

[dscho]

I cannot really help without feedback...

In the meantime, I even spent the time to build a prerelease with the updated MSYS2 runtime: https://github.com/git-for-windows/git/releases/tag/prerelease-v2.10.0.windows.1.11.geda474c

Would be nice if y'all could give it a try.

Please note that I won't be able to address any replies I receive after tomorrow until October. So now you have all the incentive you need to try this quick... 😀

[dscho]

I cannot really help without feedback.

Well, then.