git bash crashes on launch

[minnjm]

Downloaded and installed Git-2.16.1-64-bit on Windows 10 two days ago. Opened git bash, changed fonts and some others in Options... and git bash kept on crashing upon launch ever since. Uninstall/reinstall didn't solve the problem. It stopped crashing after /usrs/USERID/.minttyrc was removed. The .minttyrc file that causes git bash crashing is attached so you can reproduce the issue.

minttyrc.zip

[avih]

Same issue for me - the mintty window closes right after running git-bash.exe, but for me the offending line, as well as a minimal .minttyrc to reproduce is Term=xterm-256color, or a different minimal file: Term=vt220 (like the OP file has).

Without a Term=... line at minttyrc - it works, as well as if keeping the offending .minttyrc but adding TERM=xterm to ~/.bashrc.

Edit - the issue is apparently bash aborting:

1. Start without a .minttyrc file.
2. run git-bash.exe (works).
3. At the CLI type: TERM=vt220 (and enter) -> the window closes, probably bash aborting.

Could be related to ncurses 6.1 (I don't know if it's used by GFW), and possibly to https://github.com/Alexpux/MSYS2-packages/issues/1124 (though this issue is unaffected by TERM=vt220 value).

[avih]

Same issue for me

Sorry, my issue is with 2.16.1(2) (git version 2.16.1.windows.2), and I haven't tried earlier 2.16 versions, while OP reports the issue possibly with earlier 2.16 version . So I don't know if it's the same issue.

[avih]

Sorry, my issue is with 2.16.1(2) (git version 2.16.1.windows.2)

Still same issue and STR with 2.16.1(3).

[dscho]

@avih please understand that I have to focus on a couple of bugs that seem to affect a large percentage of Git for Windows users, while your bug seems not to affect that many users...

I think part of the reason might be that we do not ship all that many entries in /usr/share/terminfo/, and I think that there was a change in ncurses that made things crashy when files were unexpectedly not found in that directory.

If you have time to investigate further, I will be happy to guide you through installing the SDK and getting acquainted with gdb...

[avih]

I was not complaining at all, just providing additional info.

And here's another piece of info: it also happens while in a window opened by git-cmd.exe: run it, then run bin\bash (enter) and then TERM=vt220 (enter) and it exits bash and returns to the cmd.exe shell without any messages.

[dscho]

Yes, that looks like that symptom I described...

[ahogen]

This affects me. I didn't look into it this much.

I just attempted to upgrade from 2.15.1.2-64 to 2.16.1.3-64 and git-bash immediately closes on launch. Uninstalling and going back to previous version works for me.

[avih]

I think part of the reason might be that we do not ship all that many entries in /usr/share/terminfo/

This might indeed be the case with TERM=vt220:

$ infocmp.exe vt220
infocmp: couldn't open terminfo file /usr/share/terminfo/76/vt220.

And indeed this file doesn't exist.

However, the issue also exists when setting TERM=xterm-256color, and this file _does_ exist, but infocmp reports it doesn't:

$ infocmp.exe xterm-256color
infocmp: couldn't open terminfo file /usr/share/terminfo/78/xterm-256color.

$ ls /usr/share/terminfo/78/xterm-256color
/usr/share/terminfo/78/xterm-256color

I then tried copying it from Alpine linux, where it's /usr/share/terminfo/x/xterm-256color into the 78/ dir - overwriting the original xterm-256color which comes with GFW, and now both infocmp xterm-256color shows the info as well as it stops crashing.

Interestingly, the same file from MSYS2 copied into the GFW location - crashes as well.

Here are the 3 files where only the one from Alpine linux works in GFW: https://0x0.st/scaO.zip
(for some reason github doesn't let me attach a zip with these files)

[dscho]

@avih thanks for this analysis.

If you git clone --depth 1 https://github.com/git-for-windows/git-sdk-64 (it's about 540MB) and look inside there, you will see the same terminfo files as from MSYS2. I wonder, however, whether there is an assumption that the file /usr/lib/terminfo/78/xterm-256color exists (which is also in Git for Windows' SDK, as well as MSYS2), and that assumption would be violated.

Ideally, the absence of these files would of course not cause a crash, but a warning on the terminal that those files do not exist and that we fall back to TERM=dumb.

If I remember correctly, this used to be the case some time ago, but changed at some stage.

The culprit lies most likely in the ncurses package, which you should be able to rebuild using the instructions at https://github.com/git-for-windows/git/wiki/Package-management#rebuild-packages (ncurses is an MSYS2 package, so you will need to build it in an MSYS2 shell which you will get by running <git-sdk>\msys2_shell.cmd -msys and in that shell, after cd'ing to the correct location (if you followed the recommendation: /usr/src/MSYS2-packages/ncurses) and then running makepkg -s).

[ShaneHudson]

I had the same issue once I upgraded Git for Windows, deleting .minttyrc worked.

[adrianord]

@ShaneHudson Yeah, because that's where you specify TERM=[xterm-256color/vt220] which is where the bug lies. So not a particularly great solution for everyone.

[kburnik]

I was also affected by this.

My initial solution was to rename the c:\users\MyUser\.minttyrc to old.minttyrc.

before I even got to this thread (there is some mix up with bashOnWindows, at least in Google search results for "git bash opens and immediately closes windows") so it's kind of hard to locate this thread (unless you follow the documented channel and browse through the issue list for git-for-windows).

This was my .minttyrc:

BoldAsFont=no
Transparency=medium
FontHeight=12
Term=xterm-256color
CursorType=line
OpaqueWhenFocused=no
Font=Consolas
Locale=hr_HR
Charset=UTF-8

I can also confirm that xterm-256color was the offending line, so it may be a regression for the Term support. It's very subtle, I haven't really tried looking at any logs (if such exist), but it was quite frustrating.

One hint may be that starting bash.exe from cmd did work, but not git-bash.exe.

Anyway, just removing the Term=xterm-256color solved it for me, hopefully I won't feel the "lack of colors" :-D

[glhez]

I have the same problem ... but git bash (2.16.1-windows-4 + Windows 7) does not crash - the windows
simply close itself.

As I like 256 colors I'm willing to try the 540MiB SDK and gdb... but it'll take a while to download.

Do you have a hint as to where I should start using debugging ?

Beside, I don't understand:

@dscho : I wonder, however, whether there is an assumption that the file /usr/lib/terminfo/78/xterm-256color exists (which is also in Git for Windows' SDK, as well as MSYS2), and that assumption would be violated.

I'm fine with the path you indicate, but in that folder (at least in Windows), I get those:

$ ll /usr/lib/terminfo/78/xterm256
/usr/lib/terminfo/78/xterm+256color
/usr/lib/terminfo/78/xterm+256setaf
/usr/lib/terminfo/78/xterm-256color

And my TERM in .minttyrc was Term=xterm-256color

BoldAsFont=no
Font=Consolas
FontHeight=14

Term=xterm-256color

FontSmoothing=full
Locale=C
Charset=UTF-8

On a side note, does 256 colors also works on git-cmd with ConEmu ? (I use git-bash only when I'm using it from the context menu on a folder).

[avih]

does not crash - the windows simply close itself.

That's bash aborting/crashing, and because it's the only/last process - the mintty window closes.

I'm fine with the path you indicate, but in that folder (at least in Windows), I get those:

It's usr/lib/terminfo/78/xterm-256color

On a side note, does 256 colors also works on git-cmd with ConEmu

Maybe, but it's a question for conemu. Generally speaking conemu runs a windows cmd.exe shell which only supports 256 colors in recent windows 10 builds. Anyway, off topic here.

Do you have a hint as to where I should start using debugging ?

I'd set Term=xterm in ~/.minttyrc so that the window doesn't close, then run TERM=xterm-256color gdb bash and then run and supposedly it should crash and you should be able to take it from there.

[ShaneHudson]

Oddly for me although removing the file fixed the issue, resetting it to
xterm color seemed to work fine. So maybe it sets differently in latest
version?

On 12 Feb 2018 6:55 pm, "Kristijan Burnik" [e-mail] wrote:

I was also affected by this.

My initial solution was to rename the c:\users\MyUser.minttyrc to
old.minttyrc.

before I even got to this thread (there is some mix up with bashOnWindows,
at least in Google search results for "git bash opens and immediately
closes windows") so it's kind of hard to locate this thread (unless you
follow the documented channel and browse through the issue list for
git-for-windows).

This was my .minttyrc:

BoldAsFont=no
Transparency=medium
FontHeight=12
Term=xterm-256color
CursorType=line
OpaqueWhenFocused=no
Font=Consolas
Locale=hr_HR
Charset=UTF-8

I can also confirm that xterm-256color was the offending line, so it
may be a regression for the Term support. It's very subtle, I haven't
really tried looking at any logs (if such exist), but it was quite
frustrating.

One hint may be that starting bash.exe from cmd did work, but not
git-bash.exe.

Anyway, just removing the Term=xterm-256color solved it for me, hopefully
I won't feel the "lack of colors" :-D

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/git-for-windows/git/issues/1473#issuecomment-365024844,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAduXaEsguKX9ebeZ-2cRM33mYkCXXrLks5tUIkYgaJpZM4R4AR2
.

[glhez]

@ShaneHudson what did you do ? Did you put Term=xterm in minttyrc file ? (it work for me in that case).

[ShaneHudson]

Yep, that seems to be what it now has (I did it using the options window).
The colours are working fine.

On Mon, Feb 12, 2018 at 8:57 PM, glhez [e-mail] wrote:

@ShaneHudson https://github.com/shanehudson what did you do ? Did you
put Term=xterm in minttyrc file ? (it work for me in that case).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/git-for-windows/git/issues/1473#issuecomment-365059398,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAduXdsAbnalfTsjG_tIdeCg7mxQpR_xks5tUKXMgaJpZM4R4AR2
.

--

---

Shane Hudson
Website Developer
07794746595

https://ShaneHudson.net http://www.shanehudson.net/ @ShaneHudson
https://twitter.com/#!/ShaneHudson

[glhez]

@ShaneHudson seems to me that the "default" works with 256 colors too. https://askubuntu.com/questions/821157/print-a-256-color-test-pattern-in-the-terminal#821163

This mentioned script effectively print (more or less) the same color table as in the link above:

for i in {0..255} ; do
    printf "\x1b[48;5;%sm%3d\e[0m " "$i" "$i"
    if (( i == 15 )) || (( i > 15 )) && (( (i-15) % 6 == 0 )); then
        printf "\n";
    fi
done

[avih]

seems to me that the "default" works with 256 colors too

It's not an issue of mintty not able to interpret/display 256 colors SGR codes (which your program prints and mintty displays fine), but rather an issue of bash (or a lib it uses) aborting when it should read the terminfo data for a missing or unexpectedly-formatted file.

[JohnTJohnston]

After upgrading to 2.16.1.windows.4, I discovered that I am unable to launch “C:\Program Files\Gitgit-bash.exe” from installed shortcut or from command line (cmd). In both cases, the bash console flashes and closes immediately.

I am able to invoke “C:\Program Files\Git\binbash.exe” from the command line, in which case I appear to have full functionality.

I tried uninstalling and reinstalling a number of times to no effect.

Comparing a failing launch to a working launch on another computer using Process Explorer, the problem might be related to HarddiskVolume3. This error shows up near the end of the failing launch. Note the odd quote and “I” at the end of the path.

High Resolution Date & Time: 2/14/2018 6:14:13.7853585 AM
Event Class: File System
Operation: CreateFile
Result: INVALID PARAMETER
Path: \Device\HarddiskVolume3Ἵ
TID: 13904
Duration: 0.0000095
Desired Access: Generic Read
Disposition: Open
Options: Synchronous IO Non-Alert, Non-Directory File, Complete If Oplocked, Open By ID
Attributes: n/a
ShareMode: Read, Write, Delete
AllocationSize: n/a

At this point, I decided to report a bug and only then ran across this open issue.

I can confirm that renaming .minttyrc does result in a successful launch.

[dscho]

Do you have a hint as to where I should start using debugging ?

@glhez sorry for the late response; I had to put out a couple of fires here.

The way I would go forward would be to first rebuild the MinTTY package. Then, I would hand-edit the Makefile to remove any mention of the -O2 flag (most likely in a variable assignment of CFLAGS), and ensure that it has the -g flag, and then rebuild manually using make.

After that, the resulting mintty.exe should allow for single-stepping, and accurate backtraces.

Now, I would run gdb -args mintty.exe [...] and then r and wait for the crash to happen. Then a bt should show the backtrace, and l should show the currently-executed code when the crash happened (use up and down to move up and down the backtrace).

Please keep me in the loop how it goes.

[elieux]

Try mintty -h always - and inside TERM=xxx. If mintty stays and shows /usr/bin/bash aborted, then I suggest focusing on bash. Rebuild ncurses in debug mode (replace --without-debug with --with-debug and add options=(debug !strip) somewhere top), install that package, then rebuild bash (put options=(debug !strip) somewhere top) and then you should be able to debug this instance of bash. I suggest running mintty -h always ./bash then, inside echo $PPID and put that into a separate mintty with gdb ./bash -p <the-PID> inside. Then continue inside gdb, reproduce crash and inspect backtrace and stuff.

This is mostly from the top of my head, so there may be factual errors. I will try to report back soon.

[glhez]

This is the result:

bash aliases: {
  manga: rename directory, compress or extract 7z.
  mr: flatten directory for reading all in one
}
/usr/bin/bash: Aborted.

The last line is in red background.

@elieux thx I'm rebuilding both in debug. However ncurse is being downloaded when building bash.
bash failed to compile due to

case "$(uname -m)" in x86_64) MINGW_PREFIX=/mingw64;; esac && \
$MINGW_PREFIX/bin/cv2pdb "bash.exe"
E:\git\external\github\git-sdk-64\usr\src\MSYS2-packages\bash\src\bash-4.4\bash.pdb: cannot load PDB helper DLL
make: *** [Makefile:575: bash.exe] Error 1
==> ERROR: A failure occurred in build().
    Aborting...

Seems I am missing some DLL, and as far as I know, PDB are debugging file from VS++ compiler. I don't have it (and if possible, I'd like to avoid installing that, as the ISO is up to 16GiO as far as I remember ...).

[scw]

I was also affected by this issue after upgrading. Opening a git-bash session immediately closed, and it wasn't obvious what the cause was, which persisted after a clean re-installation. In my case, it was export TERM=xterm-256color in my .bash_profile. Removing that line fixed the issue, and it looks like the current xterm supports 256 colors fine. It would be nice to either resolve this issue, or document the problem in e.g. the Wiki.

[elieux]

It would be nice to either resolve this issue, or document the problem in e.g. the Wiki.

Yeah, we are working on the resolving. :)

Seems I am missing some DLL

Ah, the Git for Windows bash recipe has some modifications. I suspect it's okay to remove that part unless you want to debug using Visual Studio. details for cv2pdb

[dscho]

@glhez yes, I realized way too late that cv2pdb is not, in fact, a standalone tool but requires a Visual Studio installation (some of whose .dll files it uses).

Maybe you can get unstuck by calling git revert 0fd86d4398e3201070348491136aeb1623e641c1 in /usr/src/MSYS2-packages and then trying to build the bash package again?

[elieux]

So the debugging steps are a bit more involved that I has described. The debug options have to be declared also in the package_...() functions since otherwise they get overwritten. GDB invocation is actually gdb /usr/bin/bash <the-PID> and finding the actual PID for bash is not as easy as echo $PPID. I ended up just scanning ps and taking the latest bash PID from there.

[elieux]

The PR linked just above should work around the crash, I hope.

[mak003]

I have the same problem. Last week, when I installed the 2.16.1(4), everything was fine. But I re-installed it today, the problem happened. So I read this report, I removed the Git/usr/bin/mintty , it works.

[dscho]

But I re-installed it today, the problem happened. So I read this report, I removed the Git/usr/bin/mintty , it works.

That is not really working, that is "around-working". And instead of deleting usr\bin\mintty.exe manually, you can just choose the "ConHost" option as terminal window for Git Bash (instead of MinTTY) in the Git for Windows installer.

[mak003]

@dscho
Thank you for answer me.You are right. I install it again and choose the "ConHost" option, and It really works.

[dscho]

@elieux are there new MSYS2 packages of ncurses that we could ask the bug reporters to test?

[elieux]

Not yet.

[dscho]

But now: http://repo.msys2.org/msys/x86_64/ncurses-6.1.20180217-1-x86_64.pkg.tar.xz

I rebuilt the bash package and there is now a new snapshot: https://wingit.blob.core.windows.net/files/index.html

Can I ask y'all to test it?

[jcasale]

I can confirm the snapshot resolves the issue for me. I can once again set Term=xterm-256color without bash exiting abruptly.

[dscho]

@jcasale thank you for testing!