Git: bash.exe is Segmentation fault

[oyljerry]

• [ ] 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? Is it 32-bit or 64-bit?

git version 2.14.1.windows.1
built from commit: 82d9b3f3b2407b52251620597d4b14933685459d
sizeof-long: 4
machine: x86_64

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

 Microsoft Windows [Version 10.0.10240] 

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

 I use portable package (PortableGit-2.14.1-64-bit.7z.exe)

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

 1. go to git package bin folder
 2. run bash.exe
 3. it show test@testpc MINGW64 /bin
 4. run ls command
 5. it show "Segmentation fault"
 6. I can found a file bash.exe.stackdump in bin folder, the content is shown as below.

Stack trace:
Frame        Function    Args
000FFFF4C30  0018005D14C (000FFFFE3F4, 00000000001, 7FF83593527C, 000FFFFDE50)
000FFFF4CD0  0018005E74B (00000000064, 00000000000, 00000000304, 00000000000)
000FFFF4F20  00180121F60 (006000822EC, 00600071B99, 0000000297C, 00000050000)
000FFFF58C0  0018005D481 (00180040000, F7D4005C0000, 000FFFF52C0, 000FFFF5270)
000FFFF52C0  7FF83599666D (000FFFF5790, 000FFFF5D00, 7FF88F956365, 7FF8307AB8C0)
000FFFF52C0  7FF835913C00 (000FFFF5F00, 001803088C8, 000FFFF5A4E, 000FFFF5A10)
0000000001F  7FF83599577A (000FFFF61B0, 000FFFF61D0, 001005F6E10, 001005EB044)
0000000001F  0018009CC8E (006001C2230, 00000000000, 00100428721, 00000000002)
0000000001F  0018013FB76 (006001C2230, 00100425AD0, 00000000002, 000003A0000)
001005F6E10  0018011A60B (006001C2230, 00100425AD0, 00000000002, 000003A0000)
001005F6E10  00100428EAB (00180308B70, 00000000003, 00180131DBA, 0010000008B)
001005F6E10  00100429AC8 (000000015F0, 00000000000, 001005F1F98, 00000000000)
00000000001  00100432950 (00600000001, 006001C2700, 001800BA52C, 00000000000)
006001C3240  00100437B8A (006001C2700, 006001C2927, 00000000076, 000FFFF6548)
006001C2700  00100438BE4 (00000000001, 00600000000, 000FFFF6688, 00000000000)
006001C2940  00100439A7C (00000000000, 00000000000, 00000000000, 00000000000)
End of stack trace (more stack frames may be present)

Details

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

• 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.

 ls or any bash command 

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

work correctly 

• What actually happened instead?

 It will show Segmentation fault 

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

---

[dscho]

I cannot reproduce that here. The most obvious difference between your setup and mine seems to be:

Microsoft Windows [Version 10.0.10240]

It is Microsoft Windows [Version 10.0.15063] here...

Does Cygwin (on which part of Git for Windows is based) work? Or MSYS2?

[dscho]

I assume that one of my questions led to some sort of resolution.

[roschlau]

@dscho Myself and a few coworkers are seeing this same issue all of a sudden, with bash.exe throwing segfaults on any command we try to execute. It's confirmed to happen on Win 10 (Build 16299.611) with Git version 2.18.0 and 2.17.0, 64bit version, from the installer as well as the portable version. The interesting thing is that this started happening without us having updated git recently, the last update in my case for example was done in June. We initially suspected the IntelliJ update we had done yesterday, because we first noticed that the standalone git-bash was fine and only the one we're using from IntelliJ showed this behavior, but running bash.exe on its own, without IntelliJ still does this. We're a bit at a loss here trying to find out what is going wrong.

Git version 2.6 seems to be working.

[gwest4]

I'm also having this issue.
Git 2.18.0.windows.1
Windows 10 Pro, version 1803, build 17134.228

Every command I try results in segfault. It only happens when running bash.exe or sh.exe. Running from git-bash.exe behaves normally.

Things I've tried

• Running as Administrator
• Re-installing Git For Windows
• Installing a different version of Git For Windows (2.19.0.rc2.windows.1 and 2.16.3.windows.1)
• Running the bash.exe from freshly unpacked PortableGit
• Cleaning temp files from Windows
• Running defrag

This is a problem for me because I want to use Git Bash as the default terminal for Visual Studio Code, and you must point to C:\Program Files\Git\bin\bash.exe.

[PhilipOakley]

@gwest4 @roschlau The V2.19.0 is out, and previously the patched V2.18.2.

Do have a go with the latest version https://github.com/git-for-windows/git/releases/

[roschlau]

Turns out that it was a problem with our company's antivirus solution, trying to get an exclusion rule for the git binaries now, so probably not a problem with git itself.

[jryd]

@roschlau which antivirus solution does your company use, and which binaries did you exclude to resolve this.
I am trying to work through this exact issue now too.

[roschlau]

@jryd It's an antivirus solution by TrendMicro. Our IT support didn't have the time to work out a solution yet, so I'm still waiting on that, I'll see if I can post more info once the issue is resolved.

[jryd]

@roschlau same antivirus as mine. If you can share a fix that would be great.
I’ll raise this with my IT team on Monday also.

[roschlau]

@jryd Okay so after failed attempts to add the /Git/bin/bash.exe to the list of trusted programs we figured out that we actually had to put /Git/usr/bin/bash.exe on that list instead, and that worked, I can use the bash now as I did before. Hope this helps!

@PhilipOakley Just for the record, updating to 2.19 did not solve this issue.

[gwest4]

My company also uses TrendMicro. Can confirm that making an exception for /Git/usr/bin/bash.exe works as well.

[jryd]

@roschlau thanks! For me it was C:Program FilesGitusrbin, but adding it to the list of trusted programs did indeed fix the issue! 🎉