Crash on startup in 2.1.1 under Windows 8.1

[vadz]

I've just done a fresh almost minimal Cygwin installation under Windows 8.1 which includes mintty 2.1.1.0. Unfortunately all attempts to run it result in an immediate crash and the file mintty.exe.crashdump is created on the desktop with the following contents:

Exception: STATUS_ACCESS_VIOLATION at eip=745E4019
eax=745E4019 ebx=00000149 ecx=00000000 edx=0004028E esi=0028C7A0 edi=0028C7A0
ebp=0028CC18 esp=0028C6CC program=C:\cygwin\bin\mintty.exe, pid 1636, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame     Function  Args
0028CC18  745E4019 (80040B13, 611CBFB2, 0028CD28, 6100846A)
0028CD28  6100846A (00000000, 0028CD84, 610074F0, 00000000)
End of stack trace

[vadz]

P.S. Reverting to 2.0.3 using Cygwin installer fixed the problem, i.e. it starts up and seems to work correctly.

[mintty]

I had seen a few reports on the cygwin mailing list; it's volatile for some users and I cannot reproduce it myself, though. However, there is one change that might cause this unpleasant trouble.
Before I release that just as an attempt, could you self-compile it from the repository and try the may-be-fix, please?
https://github.com/mintty/mintty/archive/master.zip

[vadz]

The problem is that even though the binary I compile myself from the latest master (6811a75) does work, so does the version compiled here from the 2.1.1 commit (05b6035)... So it looks like there could be something problematic with the build of 2.1.1? Alternatively, perhaps it only crashes when ran for the first time (as I ran 2.0.3 since then), does it do anything special during the first run?

FWIW I've built it with "gcc version 4.5.3 (GCC)" under i686-pc-cygwin.

[Ximalas]

Same thing happened this afternoon with mintty 2.1.1 on CygWin 2.871 64 bit on Windows 7 x64 SP1:

Exception: STATUS_ACCESS_VIOLATION at rip=7FEFB3A3430
rax=000007FEFB3A3430 rbx=000000000022C5D0 rcx=00000000000A0298
rdx=000000000022C4B0 rsi=000000010042A900 rdi=000000000022C5CC
r8 =000000000022C458 r9 =00000000000A0298 r10=0000000000000000
r11=0000000000000287 r12=0000000000000120 r13=0000000000000230
r14=0000000600042390 r15=0000000000000122
rbp=000000000022C550 rsp=000000000022C488
program=G:\cygwin64\bin\mintty.exe, pid 2720, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
0000022C550 7FEFB3A3430 (0000022C550, 00000000000, 0010042A900, 00000000000)
0000022C550 0010040FAEA (0000022C550, 0010042A900, 00000000230, 0060005A370)
0000022C550 0010041B3EA (00000000000, 00000000001, 00000000030, FF0700010302FF00)
0000022CBC0 00180048410 (00000000000, 00000000000, 00000000000, 00000000000)
00000000000 001800460DC (00000000000, 00000000000, 00000000000, 00000000000)
00000000000 00180046174 (00000000000, 00000000000, 00000000000, 00000000000)
00000000000 00100419EF1 (00000000000, 00000000000, 00000000000, 00000000000)
00000000000 00100401010 (00000000000, 00000000000, 00000000000, 00000000000)
00000000000 000773659CD (00000000000, 00000000000, 00000000000, 00000000000)
00000000000 0007749B981 (00000000000, 00000000000, 00000000000, 00000000000)
End of stack trace

I did the same thing as vadz, reverted to 2.0.3, and mintty is happy.

Note that the 2.1.1 version had no problems displaying --version nor --help, so I guess something bad happens when it tries to allocate a pty.
I manually extracted the 2.1.1 executable, and oddly enough it runs perfectly when launched from mintty 2.0.3.

Would it be possible to add a mintty-debuginfo package to CygWin?

I could try to compile mintty myself as suggested above. Do I need anything in addition to gcc, some libraries perhaps? gmake?

[Ximalas]

I disabled the call to fork(), and after doing some investigations, I believe that something wrong goes on in some of the other threads. Running a debuggable version of mintty.exe through CygWin's gdb, stepping through the main thread, revealed this line at the top of the mintty window:

/bin/bash: No such file or directory

If I set the command line arguments to g:\cygwin64\bin\bash.exe, then I get a working terminal to some extent. bash complains about missing /tmp. I can type commands, but even /bin/ls is treated as ENOENT. Maybe the CygWin environment isn't properly initialised.

[Ximalas]

The crash is somehow related to the fork() call. As soon as I reenabled that call, then mintty crashed and created the stack trace. The rIP address is the same as above, 0x7FEFB3A3430.

[mintty]

Thanks for debugging. I suppose you mean the new fork() in winmain.c? That should only be called if mintty is started from a cygwin console window (Cygwin.bat environment within Windows console window). Is that the case? Any other specifics about your environment?
My patch is based on another suspicion. To compile it, gcc and make should be sufficient. Can do test it?
Many thanks.

[vadz]

FWIW I tried running the program from (Windows) Explorer and then from cmd.exe window when it crashed for me initially, so the bug is definitely not limited to the case when it runs from a Cygwin console.

[Ximalas]

Oh, I forgot to write that I ran gdb and mintty from cmd.exe. Yes, I was referring to the fork() call at line 993 of winmain.c.

[recyclebin99]

I too have the crash with mintty 2.1.1 (x86_64-pc-cygwin). But mine seems to occur only when starting mintty in a remote desktop session. I have verified this in two places - using remote desktop to my home PC from work, and after getting home with a remote desktop session to my work PC. Mintty runs fine when I run it locally, but I always get an "Exception: STATUS_ACCESS_VIOLATION" when running it via remote desktop. This occurs when running it directly from a Windows command shell or when using the standard Cygwin desktop shortcut. It was working (locally and in a remote desktop session) just before the 2.1.1 update. The only updates applied prior to the problem were mintty and (I think) 'm4'.
Both my work and home systems are running Win7-64 and 64-bit Cygwin.

[recyclebin99]

Version 2.1.2 has resolved the crashing issue I was seeing when bringing up mintty over a remote desktop connection. Locally-run mintty also works. Thank you for the effort.

[mintty]

@vadz: Only now I notice some details of your message last night about your builds. Current gcc is actually 4.9.3. So if you compiled the two commits with 4.5.3 and it works, could you update gcc and retry, please?

[Ximalas]

2.1.2 and the w32api-* stuff solved my problem. Great job!

[vadz]

@mintty Sorry, I don't have any system with 4.9.3 under Cygwin right now and am rather busy right now. If it would be really useful to you, I could try to find the time to do it, but if the bug is already fixed in 2.1.2 anyhow, I'd rather pass.