* mintty crashes on Windows 7
@ 2022-05-03 11:47 Orgad Shaneh
2022-05-03 15:23 ` Takashi Yano
0 siblings, 1 reply; 23+ messages in thread
From: Orgad Shaneh @ 2022-05-03 11:47 UTC (permalink / raw)
To: cygwin, Takashi Yano
[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]
Hi,
Running `mintty ./bash` crashes on Windows 7 on cygwin-3_3-branch.
Tested in MSYS2 on merge-3.3 branch from
https://github.com/orgads/msys2-runtime-1. It includes the tip of
cygwin-3_3-branch as of today (05827d2df8).
Steps to reproduce:
1. Start cmd.exe
2. cd <msys-directory>\usr\bin
3. mintty ./bash
GDB trace attached. Simplified form:
1 ntdll!KiRaiseUserExceptionDispatcher 0x7791b5ba
2 KERNELBASE!CloseHandle 0x7feffb31863
3 KERNEL32!CloseHandle 0x776b14f1
4 fhandler_base::close fhandler.cc 1217 0x1800682db
5 fhandler_pipe::close fhandler_pipe.cc 685 0x18009069a
6 fhandler_base::close_with_arch fhandler.cc 1193 0x18006c7d5
7 close_all_files syscalls.cc 102 0x18014548f
8 do_exit dcrt0.cc 1200 0x180048213
9 _exit dcrt0.cc 1317 0x1800483ef
10 exit exit.c 64 0x1801b3bdd
11 cygwin_exit dcrt0.cc 1311 0x1800483d3
12 _sigfe sigfe.s 35 0x18019593b
13 ??
[-- Attachment #2: gdb-trace.txt --]
[-- Type: text/plain, Size: 16597 bytes --]
Thread 5 (Thread 6896.0x1eb8 "waitproc"):
#0 0x000000007791980a in ntdll!ZwReadFile () from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#1 0x000007feffb31a6a in ReadFile () from C:\Windows\system32\KernelBase.dll
No symbol table info available.
#2 0x00000000776a0599 in ReadFile () from C:\Windows\system32\kernel32.dll
No symbol table info available.
#3 0x000000018010ca04 in proc_waiter (arg=<optimized out>) at ../../../../winsup/cygwin/pinfo.cc:1214
nb = 0
buf = 0 '\000'
vchild = {<pinfo_minimal> = {h = 0x228, hProcess = 0x22c, rd_proc_pipe = 0x220}, destroy = false, winpid_hdl = 0x0, procinfo = 0x3a0000, waiter_ready = false, wait_thread = 0x180238898 <threads+88>}
si = {si_signo = 20, si_code = 28, si_pid = 502, si_uid = 0, si_errno = 0, {__pad = {0 <repeats 32 times>}, _si_commune = {_si_code = 0, _si_read_handle = 0x0, _si_write_handle = 0x0, _si_process_handle = 0x0, {{_si_fd = 0, _si_flags = 0}, _si_pipe_unique_id = 0, _si_str = 0x0}}, {{si_sigval = {sival_int = 0, sival_ptr = 0x0}, si_value = {sival_int = 0, sival_ptr = 0x0}}, {si_tid = 0, si_overrun = 0}}, {si_status = 0, si_utime = 0, si_stime = 0}, si_addr = 0x0, {__pad2 = {0 <repeats 30 times>}, si_cyg = 0x0}}}
pid = 502
its_me = false
__PRETTY_FUNCTION__ = "DWORD proc_waiter(void*)"
#4 0x0000000180046583 in cygthread::callfunc (this=this@entry=0x180238898 <threads+88>, issimplestub=issimplestub@entry=false) at ../../../../winsup/cygwin/cygthread.cc:48
pass_arg = <optimized out>
#5 0x0000000180046b46 in cygthread::stub (arg=arg@entry=0x180238898 <threads+88>) at ../../../../winsup/cygwin/cygthread.cc:91
notify = <optimized out>
info = 0x180238898 <threads+88>
__PRETTY_FUNCTION__ = "static DWORD cygthread::stub(void*)"
#6 0x0000000180047716 in _cygtls::call2 (this=0x24ace00, func=0x180046ac0 <cygthread::stub(void*)>, arg=0x180238898 <threads+88>, buf=buf@entry=0x24acd50) at ../../../../winsup/cygwin/cygtls.cc:40
res = <optimized out>
#7 0x00000001800477c4 in _cygtls::call (func=<optimized out>, arg=<optimized out>) at ../../../../winsup/cygwin/cygtls.cc:27
buf = '\000' <repeats 2360 times>, "?M#\200\001\000\000\000\220N#\200\001\000\000\000HO#\200\001", '\000' <repeats 51 times>, "\377\377\377\377\000\000\000\000\220Y\033\200\001", '\000' <repeats 139 times>, "\001\000\000\000\000\000\000\000\016\063\315?4\022m?\336?\005\000\v", '\000' <repeats 1067 times>, "\003\000\000\000\000\000\000\000?M#\200\001", '\000' <repeats 587 times>, "\200\326?J\002", '\000' <repeats 28 times>, "\002", '\000' <repeats 1343 times>, "?\036", '\000' <repeats 158 times>, "\230\210#\200\001", '\000' <repeats 75 times>, "X?J\002", '\000' <repeats 2052 times>, "?\027c\307", '\000' <repeats 92 times>, "\nTjw", '\000' <repeats 1388 times>, "\037\000\004\033\000\000\000\000\020\004\000\000\000\000\000\000\210\371?<\000\000\000\000\000\001\000\000\000\000\000\000\000\000\000;\000\000\000\000\000k\001,P\000\000\000\000??\230w\000\000\000\000\212?<\000\000\000\000\000??<\000\000\000\000\000\200\371?<", '\000' <repeats 13 times>, "\001\000\000\000\000\000\000\000D\000\000\000\000\000\000\000 #", '\000' <repeats 30 times>, "\004\000\000\000\003\300\002\005\000\000\000\000\000\000\000\000\200\371?<\000\000\000\000\000\220?<\000\000\000\000\000\177\000\000\000\000\000\000\000\220?<", '\000' <repeats 13 times>, "D", '\000' <repeats 11 times>, "\177\000\000\000 #", '\000' <repeats 14 times>, "D", '\000' <repeats 15 times>, "\020\004", '\000' <repeats 14 times>, "\220?<\000\000\000\000\000\060\000\000\000\000\000\000\000\060\002;", '\000' <repeats 13 times>, " 6\002", '\000' <repeats 13 times>, "t\002;\000\000\000\000\000\060\002;\000\000\000\000\000\177", '\000' <repeats 39 times>, "\060\002;", '\000' <repeats 45 times>, "d#\004C", '\000' <repeats 28 times>, "\002\000\004\006", '\000' <repeats 28 times>, "(1?w", '\000' <repeats 22 times>, ";\000\000\000\000\000\000\000;\000\000\000\000\000\020\004", '\000' <repeats 14 times>, "\234{\215w\000\000\000\000\000\000;\000\000\000\000\000k\001,P\000\000\000\000\020\004\000\000\000\000\000\000@\004", '\000' <repeats 14 times>...
protect = <optimized out>
#8 0x00000000776a556d in KERNEL32!BaseThreadInitThunk () from C:\Windows\system32\kernel32.dll
No symbol table info available.
#9 0x000000007790372d in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#10 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Thread 4 (Thread 6896.0x187c):
#0 0x000000007791b0aa in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#1 0x00000000779a97c4 in ntdll!DbgUiRemoteBreakin () from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#2 0x0000000180047716 in _cygtls::call2 (this=0x22ace00, func=0x779a94c0 <ntdll!DbgUiRemoteBreakin+80>, arg=0x3c8d00, buf=buf@entry=0x22acd50) at ../../../../winsup/cygwin/cygtls.cc:40
res = <optimized out>
#3 0x00000001800477c4 in _cygtls::call (func=<optimized out>, arg=<optimized out>) at ../../../../winsup/cygwin/cygtls.cc:27
buf = '\000' <repeats 2360 times>, "?M#\200\001\000\000\000\220N#\200\001\000\000\000HO#\200\001", '\000' <repeats 203 times>, "\001\000\000\000\000\000\000\000\016\063\315?4\022m?\336?\005\000\v", '\000' <repeats 1067 times>, "\003\000\000\000\000\000\000\000?M#\200\001", '\000' <repeats 587 times>, "\200\326?*\002", '\000' <repeats 28 times>, "\002", '\000' <repeats 1343 times>, "|\030", '\000' <repeats 238 times>, "X?*\002", '\000' <repeats 2052 times>, "?\027c\307", '\000' <repeats 92 times>, "\nTjw", '\000' <repeats 1108 times>, "?o_\000\000\000\000\000?\214?w", '\000' <repeats 12 times>, "?o_\000\000\000\000\000\300__", '\000' <repeats 29 times>, "X\001_\000\000\000\000\000?\214?w\000\000\000\000\300o_", '\000' <repeats 45 times>, "x?*\002\000\000\000\000\004\000\001\005\000\000\000\000\000\000_\000\000\000\000\000?__\000\000\000\000\000\001\000\000\000\000\000\000\000?\002\000\000\000\000\000\000k\001\000P\000\000\000\000\061\000\000\000\000\000\000\000?\\_\000\000\000\000\000\020\003\000\000\000\000\000\000k\001\000P\000\000\000\000\063\020\230w\000\000\000\000\000\000_\000\000\000\000\000X\001_\000\000\000\000\000\000?*\002\000\000\000\000/\001", '\000' <repeats 30 times>, "\004\000\004\000\000\000\000\000\020\004\000\000\000\000\000\000X\303<\000\000\000\000\000\001\000\000\000\000\000\000\000\000\000;\000\000\000\000\000k\001,P\000\000\000\000??\230w\000\000\000\000Z\303<\000\000\000\000\000[\303<\000\000\000\000\000P\303<", '\000' <repeats 13 times>, "\001\000\000\000\000\000\000\000D\000\000\000\000\000\000\000?", '\000' <repeats 31 times>, "\004\000\000\000\003\300\002\005\000\000\000\000\000\000\000\000P\303<\000\000\000\000\000`\303<\000\000\000\000\000\177\000\000\000\000\000\000\000`\303<", '\000' <repeats 13 times>, "D\000\000\000\000\000\000\000\177\000\000\000\177\000\000\000?", '\000' <repeats 15 times>, "D", '\000' <repeats 15 times>, "\020\004\000\000\000\000\000\000\004\000\000\000\003\000\000\005`\303<\000\000\000\000\000\060\000\000\000\000\000\000\000\060\002;\000\000\000\000\000\177\000\000\000\000\000\000\000P\f", '\000' <repeats 14 times>, "t\002;\000\000\000\000\000\060\002;\000\000\000\000\000\177", '\000' <repeats 15 times>, "\006", '\000' <repeats 15 times>, "\060\002_\000\000\000\000\000\060\002;\000\000\000\000\000`\303<\000\000\000\000\000\070\000\000\000\000\000\000\000\060\002;", '\000' <repeats 13 times>, "@\000\000\000\000\000\000\000\307\000\004\303\000\000\000\000h\002;\000\000\000\000\000\060\002;\000\000\000\000\000\006\000\000\000\000\000\000\000\002\000\004\006", '\000' <repeats 28 times>, "(1?w", '\000' <repeats 22 times>, ";\000\000\000\000\000\000\000;\000\000\000\000\000\020\004", '\000' <repeats 14 times>, "\234{\215w\000\000\000\000\000\000;\000\000\000\000\000k\001,P\000\000\000\000\020\004\000\000\000\000\000\000@\004", '\000' <repeats 14 times>...
protect = <optimized out>
#4 0x00000000776a556d in KERNEL32!BaseThreadInitThunk () from C:\Windows\system32\kernel32.dll
No symbol table info available.
#5 0x000000007790372d in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#6 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Thread 3 (Thread 6896.0xef0):
#0 0x0000000077919d5a in ntdll!ZwWaitForMultipleObjects () from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#1 0x00000000778c332d in ntdll!RtlIsCriticalSectionLockedByThread () from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#2 0x00000000776a556d in KERNEL32!BaseThreadInitThunk () from C:\Windows\system32\kernel32.dll
No symbol table info available.
#3 0x000000007790372d in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#4 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Thread 2 (Thread 6896.0x80c "sig"):
#0 0x000000007791980a in ntdll!ZwReadFile () from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#1 0x000007feffb31a6a in ReadFile () from C:\Windows\system32\KernelBase.dll
No symbol table info available.
#2 0x00000000776a0599 in ReadFile () from C:\Windows\system32\kernel32.dll
No symbol table info available.
#3 0x00000001801356c1 in wait_sig () at ../../../../winsup/cygwin/sigproc.cc:1359
nb = 0
q = <optimized out>
pack = {si = {si_signo = 0, si_code = 0, si_pid = 0, si_uid = 0, si_errno = 0, {__pad = {0 <repeats 32 times>}, _si_commune = {_si_code = 0, _si_read_handle = 0x0, _si_write_handle = 0x0, _si_process_handle = 0x0, {{_si_fd = 0, _si_flags = 0}, _si_pipe_unique_id = 0, _si_str = 0x0}}, {{si_sigval = {sival_int = 0, sival_ptr = 0x0}, si_value = {sival_int = 0, sival_ptr = 0x0}}, {si_tid = 0, si_overrun = 0}}, {si_status = 0, si_utime = 0, si_stime = 0}, si_addr = 0x0, {__pad2 = {0 <repeats 30 times>}, si_cyg = 0x0}}}, pid = 0, sigtls = 0x0, mask = 0x0, {wakeup = 0x0, thread_handle = 0x0, next = 0x0}}
dummy_mask = 0
tl_entry = <optimized out>
clearwait = <optimized out>
sig_held = false
__PRETTY_FUNCTION__ = "void wait_sig(void*)"
#4 0x0000000180046583 in cygthread::callfunc (this=this@entry=0x180238840 <threads>, issimplestub=issimplestub@entry=false) at ../../../../winsup/cygwin/cygthread.cc:48
pass_arg = <optimized out>
#5 0x0000000180046b46 in cygthread::stub (arg=arg@entry=0x180238840 <threads>) at ../../../../winsup/cygwin/cygthread.cc:91
notify = <optimized out>
info = 0x180238840 <threads>
__PRETTY_FUNCTION__ = "static DWORD cygthread::stub(void*)"
#6 0x0000000180047716 in _cygtls::call2 (this=0x20ace00, func=0x180046ac0 <cygthread::stub(void*)>, arg=0x180238840 <threads>, buf=buf@entry=0x20acd50) at ../../../../winsup/cygwin/cygtls.cc:40
res = <optimized out>
#7 0x00000001800477c4 in _cygtls::call (func=<optimized out>, arg=<optimized out>) at ../../../../winsup/cygwin/cygtls.cc:27
buf = '\000' <repeats 2360 times>, "?M#\200\001\000\000\000\220N#\200\001\000\000\000HO#\200\001", '\000' <repeats 203 times>, "\001\000\000\000\000\000\000\000\016\063\315?4\022m?\336?\005\000\v", '\000' <repeats 1067 times>, "\003\000\000\000\000\000\000\000?M#\200\001", '\000' <repeats 587 times>, "\200\326?\n\002", '\000' <repeats 28 times>, "\002", '\000' <repeats 1343 times>, "\f\b", '\000' <repeats 158 times>, "@\210#\200\001", '\000' <repeats 75 times>, "X?\n\002", '\000' <repeats 2052 times>, "?\027c\307", '\000' <repeats 92 times>, "\nTjw", '\000' <repeats 1108 times>, "?_<\000\000\000\000\000?\214?w", '\000' <repeats 12 times>, "?_<\000\000\000\000\000\300O<", '\000' <repeats 29 times>, "X\001;\000\000\000\000\000?\214?w\000\000\000\000\a\000\004\003", '\000' <repeats 44 times>, "x?\n\002\000\000\000\000\004\000\001\005\000\000\000\000\000\000;\000\000\000\000\000?O<\000\000\000\000\000\001\000\000\000\000\000\000\000\020\004\000\000\000\000\000\000k\001,P\000\000\000\000D\000\000\000\000\000\000\000\220M<\000\000\000\000\000@\004\000\000\000\000\000\000k\001,P\000\000\000\000\063\020\230w\000\000\000\000\000\000;\000\000\000\000\000X\001;\000\000\000\000\000\000?\n\002\000\000\000\000#\001", '\000' <repeats 30 times>, "\a\000\004\003\000\000\000\000\020\004\000\000\000\000\000\000\230M<\000\000\000\000\000\001\000\000\000\000\000\000\000\000\000;\000\000\000\000\000k\001,P\000\000\000\000??\230w\000\000\000\000\232M<\000\000\000\000\000?M<\000\000\000\000\000\220M<", '\000' <repeats 13 times>, "\001\000\000\000\000\000\000\000D\000\000\000\000\000\000\000\337", '\000' <repeats 31 times>, "\004\000\000\000\003\300\002\005\000\000\000\000\000\000\000\000\220M<\000\000\000\000\000X\001;", '\000' <repeats 13 times>, "?M<", '\000' <repeats 13 times>, "D\000\000\000\000\000\000\000\177\000\000\000\177\000\000\000\337", '\000' <repeats 15 times>, "D", '\000' <repeats 15 times>, "\020\004", '\000' <repeats 14 times>, "?M<\000\000\000\000\000\060\000\000\000\000\000\000\000\060\002;\000\000\000\000\000\177\000\000\000\000\000\000\000\020\022", '\000' <repeats 22 times>, "\060\002;\000\000\000\000\000\177", '\000' <repeats 31 times>, "\060\002;\000\000\000\000\000\060\002_", '\000' <repeats 45 times>, "#\000\004'", '\000' <repeats 28 times>, "?\000\004?", '\000' <repeats 28 times>, "(1?w", '\000' <repeats 22 times>, ";\000\000\000\000\000\000\000;\000\000\000\000\000\020\004", '\000' <repeats 14 times>, "\234{\215w\000\000\000\000\000\000;\000\000\000\000\000k\001,P\000\000\000\000\020\004\000\000\000\000\000\000@\004", '\000' <repeats 14 times>...
protect = <optimized out>
#8 0x00000000776a556d in KERNEL32!BaseThreadInitThunk () from C:\Windows\system32\kernel32.dll
No symbol table info available.
#9 0x000000007790372d in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#10 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Thread 1 (Thread 6896.0x12f0 "mintty"):
#0 0x000000007791b5ba in ntdll!KiRaiseUserExceptionDispatcher () from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#1 0x000007feffb31863 in KERNELBASE!CloseHandle () from C:\Windows\system32\KernelBase.dll
No symbol table info available.
#2 0x00000000776b14f1 in KERNEL32!CloseHandle () from C:\Windows\system32\kernel32.dll
No symbol table info available.
#3 0x00000001800682db in fhandler_base::close (this=this@entry=0x180353e80) at ../../../../winsup/cygwin/fhandler.cc:1217
res = -1
__PRETTY_FUNCTION__ = "virtual int fhandler_base::close()"
#4 0x000000018009069a in fhandler_pipe::close (this=0x180353e80) at ../../../../winsup/cygwin/fhandler_pipe.cc:685
ret = <optimized out>
#5 0x000000018006c7d5 in fhandler_base::close_with_arch (this=0x180353e80) at ../../../../winsup/cygwin/fhandler.cc:1193
res = <optimized out>
fh = 0x180353e80
__PRETTY_FUNCTION__ = "int fhandler_base::close_with_arch()"
#6 0x000000018014548f in close_all_files (norelease=norelease@entry=false) at ../../../../winsup/cygwin/syscalls.cc:102
cfd = {<cygheap_fdmanip> = {_vptr.cygheap_fdmanip = <optimized out>, fd = 1, locked = false}, fh = 0x180353e80}
i = 1
h = 0x0
#7 0x0000000180048213 in do_exit (status=0) at ../../../../winsup/cygwin/dcrt0.cc:1200
__PRETTY_FUNCTION__ = "void do_exit(int)"
until_exit = {skip_unlock = true, static locker = {name = 0x1802714f6 <msg1+4086> "lock_process", sync = 1, waiters = 0, bruteforce = 0x20, visits = 2, tls = 0xffffce00}}
n = <optimized out>
#8 0x00000001800483ef in _exit (n=<optimized out>) at ../../../../winsup/cygwin/dcrt0.cc:1317
No locals.
#9 0x00000001801b3bdd in exit (code=0) at ../../../../../newlib/libc/stdlib/exit.c:64
No locals.
#10 0x00000001800483d3 in cygwin_exit (n=-17808) at ../../../../winsup/cygwin/dcrt0.cc:1311
No locals.
#11 0x000000018019593b in _sigfe () at sigfe.s:35
No locals.
#12 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-03 11:47 mintty crashes on Windows 7 Orgad Shaneh
@ 2022-05-03 15:23 ` Takashi Yano
2022-05-03 15:52 ` Orgad Shaneh
0 siblings, 1 reply; 23+ messages in thread
From: Takashi Yano @ 2022-05-03 15:23 UTC (permalink / raw)
To: cygwin; +Cc: Orgad Shaneh
On Tue, 3 May 2022 14:47:17 +0300
Orgad Shaneh wrote:
> Hi,
>
> Running `mintty ./bash` crashes on Windows 7 on cygwin-3_3-branch.
>
> Tested in MSYS2 on merge-3.3 branch from
> https://github.com/orgads/msys2-runtime-1. It includes the tip of
> cygwin-3_3-branch as of today (05827d2df8).
>
> Steps to reproduce:
> 1. Start cmd.exe
> 2. cd <msys-directory>\usr\bin
> 3. mintty ./bash
>
> GDB trace attached. Simplified form:
>
> 1 ntdll!KiRaiseUserExceptionDispatcher 0x7791b5ba
> 2 KERNELBASE!CloseHandle 0x7feffb31863
> 3 KERNEL32!CloseHandle 0x776b14f1
> 4 fhandler_base::close fhandler.cc 1217 0x1800682db
> 5 fhandler_pipe::close fhandler_pipe.cc 685 0x18009069a
> 6 fhandler_base::close_with_arch fhandler.cc 1193 0x18006c7d5
> 7 close_all_files syscalls.cc 102 0x18014548f
> 8 do_exit dcrt0.cc 1200 0x180048213
> 9 _exit dcrt0.cc 1317 0x1800483ef
> 10 exit exit.c 64 0x1801b3bdd
> 11 cygwin_exit dcrt0.cc 1311 0x1800483d3
> 12 _sigfe sigfe.s 35 0x18019593b
> 13 ??
I cannot reproduce this with cygwin git head of cygwin-3_3-branch.
Is this MSYS2 specific problem?
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-03 15:23 ` Takashi Yano
@ 2022-05-03 15:52 ` Orgad Shaneh
2022-05-03 16:10 ` Takashi Yano
0 siblings, 1 reply; 23+ messages in thread
From: Orgad Shaneh @ 2022-05-03 15:52 UTC (permalink / raw)
To: Takashi Yano; +Cc: cygwin
On Tue, May 3, 2022 at 6:23 PM Takashi Yano <takashi.yano@nifty.ne.jp> wrote:
>
> On Tue, 3 May 2022 14:47:17 +0300
> Orgad Shaneh wrote:
> > Hi,
> >
> > Running `mintty ./bash` crashes on Windows 7 on cygwin-3_3-branch.
> >
> > Tested in MSYS2 on merge-3.3 branch from
> > https://github.com/orgads/msys2-runtime-1. It includes the tip of
> > cygwin-3_3-branch as of today (05827d2df8).
> >
> I cannot reproduce this with cygwin git head of cygwin-3_3-branch.
> Is this MSYS2 specific problem?
You're right. I can't reproduce either. Only in my MSYS branch.
Can you give me some guidance how to debug it?
- Orgad
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-03 15:52 ` Orgad Shaneh
@ 2022-05-03 16:10 ` Takashi Yano
2022-05-04 9:33 ` Orgad Shaneh
0 siblings, 1 reply; 23+ messages in thread
From: Takashi Yano @ 2022-05-03 16:10 UTC (permalink / raw)
To: cygwin; +Cc: Orgad Shaneh
On Tue, 3 May 2022 18:52:28 +0300
Orgad Shaneh wrote:
> On Tue, May 3, 2022 at 6:23 PM Takashi Yano <takashi.yano@nifty.ne.jp> wrote:
> >
> > On Tue, 3 May 2022 14:47:17 +0300
> > Orgad Shaneh wrote:
> > > Hi,
> > >
> > > Running `mintty ./bash` crashes on Windows 7 on cygwin-3_3-branch.
> > >
> > > Tested in MSYS2 on merge-3.3 branch from
> > > https://github.com/orgads/msys2-runtime-1. It includes the tip of
> > > cygwin-3_3-branch as of today (05827d2df8).
> > >
> > I cannot reproduce this with cygwin git head of cygwin-3_3-branch.
> > Is this MSYS2 specific problem?
>
> You're right. I can't reproduce either. Only in my MSYS branch.
>
> Can you give me some guidance how to debug it?
If you could identify which commit causes the issue, It would help.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-03 16:10 ` Takashi Yano
@ 2022-05-04 9:33 ` Orgad Shaneh
2022-05-04 9:46 ` Orgad Shaneh
0 siblings, 1 reply; 23+ messages in thread
From: Orgad Shaneh @ 2022-05-04 9:33 UTC (permalink / raw)
To: Takashi Yano; +Cc: cygwin
On Tue, May 3, 2022 at 7:10 PM Takashi Yano <takashi.yano@nifty.ne.jp> wrote:
>
> On Tue, 3 May 2022 18:52:28 +0300
> Orgad Shaneh wrote:
> > On Tue, May 3, 2022 at 6:23 PM Takashi Yano <takashi.yano@nifty.ne.jp> wrote:
> > >
> > > On Tue, 3 May 2022 14:47:17 +0300
> > > Orgad Shaneh wrote:
> > > > Hi,
> > > >
> > > > Running `mintty ./bash` crashes on Windows 7 on cygwin-3_3-branch.
> > > >
> > > > Tested in MSYS2 on merge-3.3 branch from
> > > > https://github.com/orgads/msys2-runtime-1. It includes the tip of
> > > > cygwin-3_3-branch as of today (05827d2df8).
> > > >
> > > I cannot reproduce this with cygwin git head of cygwin-3_3-branch.
> > > Is this MSYS2 specific problem?
> >
> > You're right. I can't reproduce either. Only in my MSYS branch.
> >
> > Can you give me some guidance how to debug it?
>
> If you could identify which commit causes the issue, It would help.
0e1847fb87f5306cda6c022540560c5926627ae1 is the first bad commit
commit 0e1847fb87f5306cda6c022540560c5926627ae1
Author: Takashi Yano <takashi.yano@nifty.ne.jp>
Date: Mon Feb 28 20:25:09 2022 +0900
Cygwin: pty: Isolate CTRL_C_EVENTs between ptys.
- With this patch, unique invisible consoles are created for each pty
to isolate CTRL_C_EVENTs between ptys. This is necessary by Ctrl-C
handling in fhandler_termios::process_sigs() for non-cygwin apps
started in pty if the pseudo console is disabled.
winsup/cygwin/fhandler_termios.cc | 6 ++----
winsup/cygwin/fhandler_tty.cc | 17 +++++++++++++++++
winsup/cygwin/tty.cc | 2 ++
3 files changed, 21 insertions(+), 4 deletions(-)
I tried reverting this commit, and it fixed the crash indeed.
- Orgad
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-04 9:33 ` Orgad Shaneh
@ 2022-05-04 9:46 ` Orgad Shaneh
2022-05-04 11:16 ` Takashi Yano
0 siblings, 1 reply; 23+ messages in thread
From: Orgad Shaneh @ 2022-05-04 9:46 UTC (permalink / raw)
To: Takashi Yano; +Cc: cygwin
On Wed, May 4, 2022 at 12:33 PM Orgad Shaneh <orgads@gmail.com> wrote:
>
> On Tue, May 3, 2022 at 7:10 PM Takashi Yano <takashi.yano@nifty.ne.jp> wrote:
> >
> > On Tue, 3 May 2022 18:52:28 +0300
> > Orgad Shaneh wrote:
> > > On Tue, May 3, 2022 at 6:23 PM Takashi Yano <takashi.yano@nifty.ne.jp> wrote:
> > > >
> > > > On Tue, 3 May 2022 14:47:17 +0300
> > > > Orgad Shaneh wrote:
> > > > > Hi,
> > > > >
> > > > > Running `mintty ./bash` crashes on Windows 7 on cygwin-3_3-branch.
> > > > >
> > > > > Tested in MSYS2 on merge-3.3 branch from
> > > > > https://github.com/orgads/msys2-runtime-1. It includes the tip of
> > > > > cygwin-3_3-branch as of today (05827d2df8).
> > > > >
> > > > I cannot reproduce this with cygwin git head of cygwin-3_3-branch.
> > > > Is this MSYS2 specific problem?
> > >
> > > You're right. I can't reproduce either. Only in my MSYS branch.
> > >
> > > Can you give me some guidance how to debug it?
> >
> > If you could identify which commit causes the issue, It would help.
>
> 0e1847fb87f5306cda6c022540560c5926627ae1 is the first bad commit
> commit 0e1847fb87f5306cda6c022540560c5926627ae1
> Author: Takashi Yano <takashi.yano@nifty.ne.jp>
> Date: Mon Feb 28 20:25:09 2022 +0900
>
> Cygwin: pty: Isolate CTRL_C_EVENTs between ptys.
>
> - With this patch, unique invisible consoles are created for each pty
> to isolate CTRL_C_EVENTs between ptys. This is necessary by Ctrl-C
> handling in fhandler_termios::process_sigs() for non-cygwin apps
> started in pty if the pseudo console is disabled.
>
> winsup/cygwin/fhandler_termios.cc | 6 ++----
> winsup/cygwin/fhandler_tty.cc | 17 +++++++++++++++++
> winsup/cygwin/tty.cc | 2 ++
> 3 files changed, 21 insertions(+), 4 deletions(-)
>
> I tried reverting this commit, and it fixed the crash indeed.
>
> - Orgad
Reduced the revert to this:
@@ -979,16 +979,10 @@ fhandler_pty_slave::open (int flags, mode_t)
code does not work as expected because it calls Win32
API directly rather than cygwin read()/write(). Due to
this behaviour, protection based on attach_mutex does
not take effect. */
get_ttyp ()->need_invisible_console = true;
- else if (_major (myself->ctty) != DEV_CONS_MAJOR
- && (!get_ttyp ()->invisible_console_pid
- || !pinfo (get_ttyp ()->invisible_console_pid)))
- /* Create a new invisible console for each pty to isolate
- CTRL_C_EVENTs between ptys. */
- get_ttyp ()->need_invisible_console = true;
else
{
acquire_attach_mutex (mutex_timeout);
fhandler_console::need_invisible ();
release_attach_mutex ();
- Orgad
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-04 9:46 ` Orgad Shaneh
@ 2022-05-04 11:16 ` Takashi Yano
2022-05-04 13:27 ` Orgad Shaneh
0 siblings, 1 reply; 23+ messages in thread
From: Takashi Yano @ 2022-05-04 11:16 UTC (permalink / raw)
To: cygwin; +Cc: Orgad Shaneh
On Wed, 4 May 2022 12:46:28 +0300
Orgad Shaneh wrote:
> On Wed, May 4, 2022 at 12:33 PM Orgad Shaneh <orgads@gmail.com> wrote:
> >
> > On Tue, May 3, 2022 at 7:10 PM Takashi Yano <takashi.yano@nifty.ne.jp> wrote:
> > >
> > > On Tue, 3 May 2022 18:52:28 +0300
> > > Orgad Shaneh wrote:
> > > > On Tue, May 3, 2022 at 6:23 PM Takashi Yano <takashi.yano@nifty.ne.jp> wrote:
> > > > >
> > > > > On Tue, 3 May 2022 14:47:17 +0300
> > > > > Orgad Shaneh wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Running `mintty ./bash` crashes on Windows 7 on cygwin-3_3-branch.
> > > > > >
> > > > > > Tested in MSYS2 on merge-3.3 branch from
> > > > > > https://github.com/orgads/msys2-runtime-1. It includes the tip of
> > > > > > cygwin-3_3-branch as of today (05827d2df8).
> > > > > >
> > > > > I cannot reproduce this with cygwin git head of cygwin-3_3-branch.
> > > > > Is this MSYS2 specific problem?
> > > >
> > > > You're right. I can't reproduce either. Only in my MSYS branch.
> > > >
> > > > Can you give me some guidance how to debug it?
> > >
> > > If you could identify which commit causes the issue, It would help.
> >
> > 0e1847fb87f5306cda6c022540560c5926627ae1 is the first bad commit
> > commit 0e1847fb87f5306cda6c022540560c5926627ae1
> > Author: Takashi Yano <takashi.yano@nifty.ne.jp>
> > Date: Mon Feb 28 20:25:09 2022 +0900
> >
> > Cygwin: pty: Isolate CTRL_C_EVENTs between ptys.
> >
> > - With this patch, unique invisible consoles are created for each pty
> > to isolate CTRL_C_EVENTs between ptys. This is necessary by Ctrl-C
> > handling in fhandler_termios::process_sigs() for non-cygwin apps
> > started in pty if the pseudo console is disabled.
> >
> > winsup/cygwin/fhandler_termios.cc | 6 ++----
> > winsup/cygwin/fhandler_tty.cc | 17 +++++++++++++++++
> > winsup/cygwin/tty.cc | 2 ++
> > 3 files changed, 21 insertions(+), 4 deletions(-)
> >
> > I tried reverting this commit, and it fixed the crash indeed.
> >
> > - Orgad
>
> Reduced the revert to this:
> @@ -979,16 +979,10 @@ fhandler_pty_slave::open (int flags, mode_t)
> code does not work as expected because it calls Win32
> API directly rather than cygwin read()/write(). Due to
> this behaviour, protection based on attach_mutex does
> not take effect. */
> get_ttyp ()->need_invisible_console = true;
> - else if (_major (myself->ctty) != DEV_CONS_MAJOR
> - && (!get_ttyp ()->invisible_console_pid
> - || !pinfo (get_ttyp ()->invisible_console_pid)))
> - /* Create a new invisible console for each pty to isolate
> - CTRL_C_EVENTs between ptys. */
> - get_ttyp ()->need_invisible_console = true;
> else
> {
> acquire_attach_mutex (mutex_timeout);
> fhandler_console::need_invisible ();
> release_attach_mutex ();
A few things about this.
1) bash exits with exit code 127 for 'mintty bash'
2) 'mintty bash' does not work, but 'mintty ash' and 'mintty tcsh' work.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-04 11:16 ` Takashi Yano
@ 2022-05-04 13:27 ` Orgad Shaneh
2022-05-05 1:20 ` Takashi Yano
0 siblings, 1 reply; 23+ messages in thread
From: Orgad Shaneh @ 2022-05-04 13:27 UTC (permalink / raw)
To: Takashi Yano; +Cc: cygwin
On Wed, May 4, 2022 at 2:16 PM Takashi Yano <takashi.yano@nifty.ne.jp> wrote:
>
> > Reduced the revert to this:
> > @@ -979,16 +979,10 @@ fhandler_pty_slave::open (int flags, mode_t)
> > code does not work as expected because it calls Win32
> > API directly rather than cygwin read()/write(). Due to
> > this behaviour, protection based on attach_mutex does
> > not take effect. */
> > get_ttyp ()->need_invisible_console = true;
> > - else if (_major (myself->ctty) != DEV_CONS_MAJOR
> > - && (!get_ttyp ()->invisible_console_pid
> > - || !pinfo (get_ttyp ()->invisible_console_pid)))
> > - /* Create a new invisible console for each pty to isolate
> > - CTRL_C_EVENTs between ptys. */
> > - get_ttyp ()->need_invisible_console = true;
> > else
> > {
> > acquire_attach_mutex (mutex_timeout);
> > fhandler_console::need_invisible ();
> > release_attach_mutex ();
>
> A few things about this.
>
> 1) bash exits with exit code 127 for 'mintty bash'
> 2) 'mintty bash' does not work, but 'mintty ash' and 'mintty tcsh' work.
Right. mintty dash also works.
Notice that I did *not* set enable_pcon (not supported on Win7 anyway).
- Orgad
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-04 13:27 ` Orgad Shaneh
@ 2022-05-05 1:20 ` Takashi Yano
2022-05-05 1:27 ` Takashi Yano
0 siblings, 1 reply; 23+ messages in thread
From: Takashi Yano @ 2022-05-05 1:20 UTC (permalink / raw)
To: cygwin; +Cc: Orgad Shaneh
On Wed, 4 May 2022 16:27:43 +0300
Orgad Shaneh wrote:
> On Wed, May 4, 2022 at 2:16 PM Takashi Yano <takashi.yano@nifty.ne.jp> wrote:
> >
> > > Reduced the revert to this:
> > > @@ -979,16 +979,10 @@ fhandler_pty_slave::open (int flags, mode_t)
> > > code does not work as expected because it calls Win32
> > > API directly rather than cygwin read()/write(). Due to
> > > this behaviour, protection based on attach_mutex does
> > > not take effect. */
> > > get_ttyp ()->need_invisible_console = true;
> > > - else if (_major (myself->ctty) != DEV_CONS_MAJOR
> > > - && (!get_ttyp ()->invisible_console_pid
> > > - || !pinfo (get_ttyp ()->invisible_console_pid)))
> > > - /* Create a new invisible console for each pty to isolate
> > > - CTRL_C_EVENTs between ptys. */
> > > - get_ttyp ()->need_invisible_console = true;
> > > else
> > > {
> > > acquire_attach_mutex (mutex_timeout);
> > > fhandler_console::need_invisible ();
> > > release_attach_mutex ();
> >
> > A few things about this.
> >
> > 1) bash exits with exit code 127 for 'mintty bash'
> > 2) 'mintty bash' does not work, but 'mintty ash' and 'mintty tcsh' work.
>
> Right. mintty dash also works.
>
> Notice that I did *not* set enable_pcon (not supported on Win7 anyway).
Even without that commit (and also with msys2 3.3.4 release),
something wrong with msys2 in Windows 7.
If you run script command (/usr/bin/script), bash crashes in
similar way. typescript file generated by script command is
as follows.
Script started on 2022-05-05 10:12:28+09:00 [TERM="cygwin" TTY="/dev/cons0" COLUMNS="80" LINES="25"]
Script done on 2022-05-05 10:12:29+09:00 [COMMAND_EXIT_CODE="127"]
bash also exited with exit code 127.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-05 1:20 ` Takashi Yano
@ 2022-05-05 1:27 ` Takashi Yano
2022-05-05 1:59 ` Takashi Yano
0 siblings, 1 reply; 23+ messages in thread
From: Takashi Yano @ 2022-05-05 1:27 UTC (permalink / raw)
To: cygwin; +Cc: Orgad Shaneh
On Thu, 5 May 2022 10:20:45 +0900
Takashi Yano <takashi.yano@nifty.ne.jp> wrote:
> On Wed, 4 May 2022 16:27:43 +0300
> Orgad Shaneh wrote:
> > On Wed, May 4, 2022 at 2:16 PM Takashi Yano <takashi.yano@nifty.ne.jp> wrote:
> > >
> > > > Reduced the revert to this:
> > > > @@ -979,16 +979,10 @@ fhandler_pty_slave::open (int flags, mode_t)
> > > > code does not work as expected because it calls Win32
> > > > API directly rather than cygwin read()/write(). Due to
> > > > this behaviour, protection based on attach_mutex does
> > > > not take effect. */
> > > > get_ttyp ()->need_invisible_console = true;
> > > > - else if (_major (myself->ctty) != DEV_CONS_MAJOR
> > > > - && (!get_ttyp ()->invisible_console_pid
> > > > - || !pinfo (get_ttyp ()->invisible_console_pid)))
> > > > - /* Create a new invisible console for each pty to isolate
> > > > - CTRL_C_EVENTs between ptys. */
> > > > - get_ttyp ()->need_invisible_console = true;
> > > > else
> > > > {
> > > > acquire_attach_mutex (mutex_timeout);
> > > > fhandler_console::need_invisible ();
> > > > release_attach_mutex ();
> > >
> > > A few things about this.
> > >
> > > 1) bash exits with exit code 127 for 'mintty bash'
> > > 2) 'mintty bash' does not work, but 'mintty ash' and 'mintty tcsh' work.
> >
> > Right. mintty dash also works.
> >
> > Notice that I did *not* set enable_pcon (not supported on Win7 anyway).
>
> Even without that commit (and also with msys2 3.3.4 release),
> something wrong with msys2 in Windows 7.
>
> If you run script command (/usr/bin/script), bash crashes in
> similar way. typescript file generated by script command is
> as follows.
>
> Script started on 2022-05-05 10:12:28+09:00 [TERM="cygwin" TTY="/dev/cons0" COLUMNS="80" LINES="25"]
>
> Script done on 2022-05-05 10:12:29+09:00 [COMMAND_EXIT_CODE="127"]
>
> bash also exited with exit code 127.
Ah, this only occurs if script command is started in console.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-05 1:27 ` Takashi Yano
@ 2022-05-05 1:59 ` Takashi Yano
2022-05-05 3:33 ` Takashi Yano
0 siblings, 1 reply; 23+ messages in thread
From: Takashi Yano @ 2022-05-05 1:59 UTC (permalink / raw)
To: cygwin; +Cc: Orgad Shaneh
On Thu, 5 May 2022 10:27:24 +0900
Takashi Yano wrote:
> On Thu, 5 May 2022 10:20:45 +0900
> Takashi Yano wrote:
>
> > On Wed, 4 May 2022 16:27:43 +0300
> > Orgad Shaneh wrote:
> > > On Wed, May 4, 2022 at 2:16 PM Takashi Yano <takashi.yano@nifty.ne.jp> wrote:
> > > >
> > > > > Reduced the revert to this:
> > > > > @@ -979,16 +979,10 @@ fhandler_pty_slave::open (int flags, mode_t)
> > > > > code does not work as expected because it calls Win32
> > > > > API directly rather than cygwin read()/write(). Due to
> > > > > this behaviour, protection based on attach_mutex does
> > > > > not take effect. */
> > > > > get_ttyp ()->need_invisible_console = true;
> > > > > - else if (_major (myself->ctty) != DEV_CONS_MAJOR
> > > > > - && (!get_ttyp ()->invisible_console_pid
> > > > > - || !pinfo (get_ttyp ()->invisible_console_pid)))
> > > > > - /* Create a new invisible console for each pty to isolate
> > > > > - CTRL_C_EVENTs between ptys. */
> > > > > - get_ttyp ()->need_invisible_console = true;
> > > > > else
> > > > > {
> > > > > acquire_attach_mutex (mutex_timeout);
> > > > > fhandler_console::need_invisible ();
> > > > > release_attach_mutex ();
> > > >
> > > > A few things about this.
> > > >
> > > > 1) bash exits with exit code 127 for 'mintty bash'
> > > > 2) 'mintty bash' does not work, but 'mintty ash' and 'mintty tcsh' work.
> > >
> > > Right. mintty dash also works.
> > >
> > > Notice that I did *not* set enable_pcon (not supported on Win7 anyway).
> >
> > Even without that commit (and also with msys2 3.3.4 release),
> > something wrong with msys2 in Windows 7.
> >
> > If you run script command (/usr/bin/script), bash crashes in
> > similar way. typescript file generated by script command is
> > as follows.
> >
> > Script started on 2022-05-05 10:12:28+09:00 [TERM="cygwin" TTY="/dev/cons0" COLUMNS="80" LINES="25"]
> >
> > Script done on 2022-05-05 10:12:29+09:00 [COMMAND_EXIT_CODE="127"]
> >
> > bash also exited with exit code 127.
>
> Ah, this only occurs if script command is started in console.
And also this is caused by:
get_ttyp ()->need_invisible_console = true;
at another place.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-05 1:59 ` Takashi Yano
@ 2022-05-05 3:33 ` Takashi Yano
2022-05-05 4:41 ` Takashi Yano
0 siblings, 1 reply; 23+ messages in thread
From: Takashi Yano @ 2022-05-05 3:33 UTC (permalink / raw)
To: cygwin; +Cc: Orgad Shaneh
On Thu, 5 May 2022 10:59:54 +0900
Takashi Yano wrote:
> On Thu, 5 May 2022 10:27:24 +0900
> Takashi Yano wrote:
> > On Thu, 5 May 2022 10:20:45 +0900
> > Takashi Yano wrote:
> >
> > > On Wed, 4 May 2022 16:27:43 +0300
> > > Orgad Shaneh wrote:
> > > > On Wed, May 4, 2022 at 2:16 PM Takashi Yano <takashi.yano@nifty.ne.jp> wrote:
> > > > >
> > > > > > Reduced the revert to this:
> > > > > > @@ -979,16 +979,10 @@ fhandler_pty_slave::open (int flags, mode_t)
> > > > > > code does not work as expected because it calls Win32
> > > > > > API directly rather than cygwin read()/write(). Due to
> > > > > > this behaviour, protection based on attach_mutex does
> > > > > > not take effect. */
> > > > > > get_ttyp ()->need_invisible_console = true;
> > > > > > - else if (_major (myself->ctty) != DEV_CONS_MAJOR
> > > > > > - && (!get_ttyp ()->invisible_console_pid
> > > > > > - || !pinfo (get_ttyp ()->invisible_console_pid)))
> > > > > > - /* Create a new invisible console for each pty to isolate
> > > > > > - CTRL_C_EVENTs between ptys. */
> > > > > > - get_ttyp ()->need_invisible_console = true;
> > > > > > else
> > > > > > {
> > > > > > acquire_attach_mutex (mutex_timeout);
> > > > > > fhandler_console::need_invisible ();
> > > > > > release_attach_mutex ();
> > > > >
> > > > > A few things about this.
> > > > >
> > > > > 1) bash exits with exit code 127 for 'mintty bash'
> > > > > 2) 'mintty bash' does not work, but 'mintty ash' and 'mintty tcsh' work.
> > > >
> > > > Right. mintty dash also works.
> > > >
> > > > Notice that I did *not* set enable_pcon (not supported on Win7 anyway).
> > >
> > > Even without that commit (and also with msys2 3.3.4 release),
> > > something wrong with msys2 in Windows 7.
> > >
> > > If you run script command (/usr/bin/script), bash crashes in
> > > similar way. typescript file generated by script command is
> > > as follows.
> > >
> > > Script started on 2022-05-05 10:12:28+09:00 [TERM="cygwin" TTY="/dev/cons0" COLUMNS="80" LINES="25"]
> > >
> > > Script done on 2022-05-05 10:12:29+09:00 [COMMAND_EXIT_CODE="127"]
> > >
> > > bash also exited with exit code 127.
> >
> > Ah, this only occurs if script command is started in console.
>
> And also this is caused by:
> get_ttyp ()->need_invisible_console = true;
> at another place.
I found that bash crashes at:
h = GetProcessWindowStation ();
in fhandler_console::need_invisible().
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-05 3:33 ` Takashi Yano
@ 2022-05-05 4:41 ` Takashi Yano
2022-05-05 6:44 ` Takashi Yano
0 siblings, 1 reply; 23+ messages in thread
From: Takashi Yano @ 2022-05-05 4:41 UTC (permalink / raw)
To: cygwin; +Cc: Orgad Shaneh
On Thu, 5 May 2022 12:33:07 +0900
Takashi Yano wrote:
> On Thu, 5 May 2022 10:59:54 +0900
> Takashi Yano wrote:
> > On Thu, 5 May 2022 10:27:24 +0900
> > Takashi Yano wrote:
> > > On Thu, 5 May 2022 10:20:45 +0900
> > > Takashi Yano wrote:
> > >
> > > > On Wed, 4 May 2022 16:27:43 +0300
> > > > Orgad Shaneh wrote:
> > > > > On Wed, May 4, 2022 at 2:16 PM Takashi Yano <takashi.yano@nifty.ne.jp> wrote:
> > > > > >
> > > > > > > Reduced the revert to this:
> > > > > > > @@ -979,16 +979,10 @@ fhandler_pty_slave::open (int flags, mode_t)
> > > > > > > code does not work as expected because it calls Win32
> > > > > > > API directly rather than cygwin read()/write(). Due to
> > > > > > > this behaviour, protection based on attach_mutex does
> > > > > > > not take effect. */
> > > > > > > get_ttyp ()->need_invisible_console = true;
> > > > > > > - else if (_major (myself->ctty) != DEV_CONS_MAJOR
> > > > > > > - && (!get_ttyp ()->invisible_console_pid
> > > > > > > - || !pinfo (get_ttyp ()->invisible_console_pid)))
> > > > > > > - /* Create a new invisible console for each pty to isolate
> > > > > > > - CTRL_C_EVENTs between ptys. */
> > > > > > > - get_ttyp ()->need_invisible_console = true;
> > > > > > > else
> > > > > > > {
> > > > > > > acquire_attach_mutex (mutex_timeout);
> > > > > > > fhandler_console::need_invisible ();
> > > > > > > release_attach_mutex ();
> > > > > >
> > > > > > A few things about this.
> > > > > >
> > > > > > 1) bash exits with exit code 127 for 'mintty bash'
> > > > > > 2) 'mintty bash' does not work, but 'mintty ash' and 'mintty tcsh' work.
> > > > >
> > > > > Right. mintty dash also works.
> > > > >
> > > > > Notice that I did *not* set enable_pcon (not supported on Win7 anyway).
> > > >
> > > > Even without that commit (and also with msys2 3.3.4 release),
> > > > something wrong with msys2 in Windows 7.
> > > >
> > > > If you run script command (/usr/bin/script), bash crashes in
> > > > similar way. typescript file generated by script command is
> > > > as follows.
> > > >
> > > > Script started on 2022-05-05 10:12:28+09:00 [TERM="cygwin" TTY="/dev/cons0" COLUMNS="80" LINES="25"]
> > > >
> > > > Script done on 2022-05-05 10:12:29+09:00 [COMMAND_EXIT_CODE="127"]
> > > >
> > > > bash also exited with exit code 127.
> > >
> > > Ah, this only occurs if script command is started in console.
> >
> > And also this is caused by:
> > get_ttyp ()->need_invisible_console = true;
> > at another place.
>
> I found that bash crashes at:
> h = GetProcessWindowStation ();
> in fhandler_console::need_invisible().
I downloaded bash source files from:
https://git.savannah.gnu.org/git/bash.git
and built it by:
./configure && make
and replaced /usr/bin/bash.
Then the issue disappeared.
Now, I start to suspect the issue is a bug of msys2 bash package.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-05 4:41 ` Takashi Yano
@ 2022-05-05 6:44 ` Takashi Yano
2022-05-05 22:48 ` Takashi Yano
0 siblings, 1 reply; 23+ messages in thread
From: Takashi Yano @ 2022-05-05 6:44 UTC (permalink / raw)
To: cygwin; +Cc: Orgad Shaneh
On Thu, 5 May 2022 13:41:20 +0900
Takashi Yano wrote:
> I downloaded bash source files from:
> https://git.savannah.gnu.org/git/bash.git
> and built it by:
> ./configure && make
> and replaced /usr/bin/bash.
>
> Then the issue disappeared.
> Now, I start to suspect the issue is a bug of msys2 bash package.
I tried several shells and results are as follows.
tcsh: ok
ash: ok
dash: ok
zsh: ok
ksh: ok
fish: ok
bash (build from original source): ok
bash (from msys2 package): ng
Only bash in msys2 package fails.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-05 6:44 ` Takashi Yano
@ 2022-05-05 22:48 ` Takashi Yano
2022-05-06 14:05 ` Orgad Shaneh
0 siblings, 1 reply; 23+ messages in thread
From: Takashi Yano @ 2022-05-05 22:48 UTC (permalink / raw)
To: cygwin; +Cc: Orgad Shaneh
On Thu, 5 May 2022 15:44:40 +0900
Takashi Yano wrote:
> On Thu, 5 May 2022 13:41:20 +0900
> Takashi Yano wrote:
> > I downloaded bash source files from:
> > https://git.savannah.gnu.org/git/bash.git
> > and built it by:
> > ./configure && make
> > and replaced /usr/bin/bash.
> >
> > Then the issue disappeared.
> > Now, I start to suspect the issue is a bug of msys2 bash package.
>
> I tried several shells and results are as follows.
>
> tcsh: ok
> ash: ok
> dash: ok
> zsh: ok
> ksh: ok
> fish: ok
> bash (build from original source): ok
>
> bash (from msys2 package): ng
>
> Only bash in msys2 package fails.
I identified the difference which causes the issue
between bash built from original source and msys2 bash.
If --enable-readline and --with-installed-readline is specified
to configure, the problem causes even with bash built from original
source.
Also, removing --with-installed-readline from configure and removing
READLINE_LDFLAGS= from make in PKGBUILD of MSYS2 bash package solves
the issue.
So it seems to be a readline problem, not a bug in bash itself.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-05 22:48 ` Takashi Yano
@ 2022-05-06 14:05 ` Orgad Shaneh
2022-05-06 17:22 ` Brian Inglis
` (2 more replies)
0 siblings, 3 replies; 23+ messages in thread
From: Orgad Shaneh @ 2022-05-06 14:05 UTC (permalink / raw)
To: Takashi Yano; +Cc: cygwin, Johannes Schindelin
On Fri, May 6, 2022 at 1:49 AM Takashi Yano <takashi.yano@nifty.ne.jp> wrote:
> > Only bash in msys2 package fails.
>
> I identified the difference which causes the issue
> between bash built from original source and msys2 bash.
>
> If --enable-readline and --with-installed-readline is specified
> to configure, the problem causes even with bash built from original
> source.
>
> Also, removing --with-installed-readline from configure and removing
> READLINE_LDFLAGS= from make in PKGBUILD of MSYS2 bash package solves
> the issue.
>
> So it seems to be a readline problem, not a bug in bash itself.
Adding @Johannes Schindelin to the loop.
Thanks for your investigation so far.
So how do we proceed, assuming MSYS project does want to use the
installed readline? I checked the readline PKGBUILD, and it only has
very basic patches, none of them looks suspicious.
Is (external) readline not used in cygwin/bash?
Do you suggest that there's a bug in readline, that your change in the
runtime uncovered? Or is it the other way around?
What might we break if we revert the part I referenced earlier in
fhandler_tty.cc?
- Orgad
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-06 14:05 ` Orgad Shaneh
@ 2022-05-06 17:22 ` Brian Inglis
2022-05-06 19:02 ` Takashi Yano
2022-05-06 19:16 ` Johannes Schindelin
2 siblings, 0 replies; 23+ messages in thread
From: Brian Inglis @ 2022-05-06 17:22 UTC (permalink / raw)
To: cygwin
On 2022-05-06 08:05, Orgad Shaneh wrote:
> On Fri, May 6, 2022 at 1:49 AM Takashi Yano wrote:
>>> Only bash in msys2 package fails.
>> I identified the difference which causes the issue
>> between bash built from original source and msys2 bash.
>> If --enable-readline and --with-installed-readline is specified
>> to configure, the problem causes even with bash built from original
>> source.
>> Also, removing --with-installed-readline from configure and removing
>> READLINE_LDFLAGS= from make in PKGBUILD of MSYS2 bash package solves
>> the issue.
>> So it seems to be a readline problem, not a bug in bash itself.
> Adding @Johannes Schindelin to the loop.
> Thanks for your investigation so far.
> So how do we proceed, assuming MSYS project does want to use the
> installed readline? I checked the readline PKGBUILD, and it only has
> very basic patches, none of them looks suspicious.
> Is (external) readline not used in cygwin/bash?
> Do you suggest that there's a bug in readline, that your change in the
> runtime uncovered? Or is it the other way around?
> What might we break if we revert the part I referenced earlier in
> fhandler_tty.cc?
Cygwin bash and other packages use the latest readline 8.1 library package:
$ cygstart https://cygwin.com/packages/summary/readline-src.html
$ cygcheck -l libreadline7
/usr/bin/cygreadline7.dll
/usr/bin/cyghistory7.dll
What readline does MSYS2 bash use - it requires libreadline-devel to
build, but does not have any readline dependency, nor is libreadline
required by bash:
https://packages.msys2.org/package/bash
https://packages.msys2.org/package/libreadline
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-06 14:05 ` Orgad Shaneh
2022-05-06 17:22 ` Brian Inglis
@ 2022-05-06 19:02 ` Takashi Yano
2022-05-06 19:16 ` Johannes Schindelin
2 siblings, 0 replies; 23+ messages in thread
From: Takashi Yano @ 2022-05-06 19:02 UTC (permalink / raw)
To: cygwin; +Cc: Johannes Schindelin, Orgad Shaneh
On Fri, 6 May 2022 17:05:02 +0300
Orgad Shaneh wrote:
> On Fri, May 6, 2022 at 1:49 AM Takashi Yano <takashi.yano@nifty.ne.jp> wrote:
> > > Only bash in msys2 package fails.
> >
> > I identified the difference which causes the issue
> > between bash built from original source and msys2 bash.
> >
> > If --enable-readline and --with-installed-readline is specified
> > to configure, the problem causes even with bash built from original
> > source.
> >
> > Also, removing --with-installed-readline from configure and removing
> > READLINE_LDFLAGS= from make in PKGBUILD of MSYS2 bash package solves
> > the issue.
> >
> > So it seems to be a readline problem, not a bug in bash itself.
>
> Adding @Johannes Schindelin to the loop.
>
> Thanks for your investigation so far.
>
> So how do we proceed, assuming MSYS project does want to use the
> installed readline? I checked the readline PKGBUILD, and it only has
> very basic patches, none of them looks suspicious.
>
> Is (external) readline not used in cygwin/bash?
In cygwin the issue does not occur even with bash
configured with --enable-readline and --with-installed-readline.
> Do you suggest that there's a bug in readline, that your change in the
> runtime uncovered? Or is it the other way around?
I suspect it's the former.
> What might we break if we revert the part I referenced earlier in
> fhandler_tty.cc?
If you revert that commit, non-cygwin app recieves ctrl-c twice
in the following scenario.
1) Start mintty
2) Run cmd.exe
3) Run script command
4) Run non-cygwin app
5) Press ctrl-c
This is becase ctrl-c is processed by both mintty pty master
and script pty master.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-06 14:05 ` Orgad Shaneh
2022-05-06 17:22 ` Brian Inglis
2022-05-06 19:02 ` Takashi Yano
@ 2022-05-06 19:16 ` Johannes Schindelin
2022-05-06 20:13 ` Takashi Yano
2 siblings, 1 reply; 23+ messages in thread
From: Johannes Schindelin @ 2022-05-06 19:16 UTC (permalink / raw)
To: Orgad Shaneh; +Cc: Takashi Yano, cygwin
Hi Orgad,
On Fri, 6 May 2022, Orgad Shaneh wrote:
> Adding @Johannes Schindelin to the loop.
Thank you, but that unfortunately does not work on this list. Due to the
policy to never reply-to-all, the subsequent replies immediately lost me.
The reason why MSYS2's Bash does not depend on the `libreadline` package
is that `bash.exe` is linked _statically_ to that library.
Takashi, for the record, I find it hard to believe that the bug is
libreadline's because Orgad's scenario works if he reverts that patch in
the _MSYS2 runtime_, _and_ it is rather dubious that libreadline would
potentially do anything that makes a call to `GetProcessWindowStation()`
not fail but _crash_.
These console patches sure are gifts that keep on giving.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-06 19:16 ` Johannes Schindelin
@ 2022-05-06 20:13 ` Takashi Yano
2022-05-07 0:20 ` Takashi Yano
0 siblings, 1 reply; 23+ messages in thread
From: Takashi Yano @ 2022-05-06 20:13 UTC (permalink / raw)
To: cygwin; +Cc: Orgad Shaneh, Johannes Schindelin
On Fri, 6 May 2022 21:16:10 +0200 (CEST)
Johannes Schindelin wrote:
> Takashi, for the record, I find it hard to believe that the bug is
> libreadline's because Orgad's scenario works if he reverts that patch in
> the _MSYS2 runtime_, _and_ it is rather dubious that libreadline would
> potentially do anything that makes a call to `GetProcessWindowStation()`
> not fail but _crash_.
I found the following test case also crashes with that commit.
1) Compile rl_stc.c with gcc rl_stc.c -lreadline -o rl_stc.c
2) mintty --hold always ./rl_stc
/* rl_stc.c */
#include <stdio.h>
#include <stdlib.h>
#include <readline/readline.h>
int main(int argc, char *argv[])
{
char *str;
if (argc > 1) {
str = readline(">> ");
printf("%s\n", str);
free(str);
}
return 0;
}
In this test case, no args is specified, so readline() is
not called. However, this crashes indeed. This means just
loading msys-readline8.dll causes the crash.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-06 20:13 ` Takashi Yano
@ 2022-05-07 0:20 ` Takashi Yano
2022-05-08 11:08 ` Takashi Yano
0 siblings, 1 reply; 23+ messages in thread
From: Takashi Yano @ 2022-05-07 0:20 UTC (permalink / raw)
To: cygwin; +Cc: Johannes Schindelin, Orgad Shaneh
On Sat, 7 May 2022 05:13:23 +0900
Takashi Yano wrote:
> On Fri, 6 May 2022 21:16:10 +0200 (CEST)
> Johannes Schindelin wrote:
> > Takashi, for the record, I find it hard to believe that the bug is
> > libreadline's because Orgad's scenario works if he reverts that patch in
> > the _MSYS2 runtime_, _and_ it is rather dubious that libreadline would
> > potentially do anything that makes a call to `GetProcessWindowStation()`
> > not fail but _crash_.
>
> I found the following test case also crashes with that commit.
>
> 1) Compile rl_stc.c with gcc rl_stc.c -lreadline -o rl_stc.c
> 2) mintty --hold always ./rl_stc
>
> /* rl_stc.c */
> #include <stdio.h>
> #include <stdlib.h>
> #include <readline/readline.h>
>
> int main(int argc, char *argv[])
> {
> char *str;
> if (argc > 1) {
> str = readline(">> ");
> printf("%s\n", str);
> free(str);
> }
> return 0;
> }
>
> In this test case, no args is specified, so readline() is
> not called. However, this crashes indeed. This means just
> loading msys-readline8.dll causes the crash.
1') gcc --static rl_stc.c -lreadline -lncurses -o rl_stc.c
2) mintty --hold always ./rl_stc
also causes crash. In this case, no code from libreadline is
executed, I think. Why this triggers GetProcessWindowStation()
crash?
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-07 0:20 ` Takashi Yano
@ 2022-05-08 11:08 ` Takashi Yano
2022-05-08 11:22 ` Orgad Shaneh
0 siblings, 1 reply; 23+ messages in thread
From: Takashi Yano @ 2022-05-08 11:08 UTC (permalink / raw)
To: cygwin; +Cc: Johannes Schindelin, Orgad Shaneh
On Sat, 7 May 2022 09:20:51 +0900
Takashi Yano wrote:
> On Sat, 7 May 2022 05:13:23 +0900
> Takashi Yano wrote:
> > On Fri, 6 May 2022 21:16:10 +0200 (CEST)
> > Johannes Schindelin wrote:
> > > Takashi, for the record, I find it hard to believe that the bug is
> > > libreadline's because Orgad's scenario works if he reverts that patch in
> > > the _MSYS2 runtime_, _and_ it is rather dubious that libreadline would
> > > potentially do anything that makes a call to `GetProcessWindowStation()`
> > > not fail but _crash_.
> >
> > I found the following test case also crashes with that commit.
> >
> > 1) Compile rl_stc.c with gcc rl_stc.c -lreadline -o rl_stc.c
> > 2) mintty --hold always ./rl_stc
> >
> > /* rl_stc.c */
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <readline/readline.h>
> >
> > int main(int argc, char *argv[])
> > {
> > char *str;
> > if (argc > 1) {
> > str = readline(">> ");
> > printf("%s\n", str);
> > free(str);
> > }
> > return 0;
> > }
> >
> > In this test case, no args is specified, so readline() is
> > not called. However, this crashes indeed. This means just
> > loading msys-readline8.dll causes the crash.
>
> 1') gcc --static rl_stc.c -lreadline -lncurses -o rl_stc.c
> 2) mintty --hold always ./rl_stc
>
> also causes crash. In this case, no code from libreadline is
> executed, I think. Why this triggers GetProcessWindowStation()
> crash?
I have pushed two patches to cygwin-3_3-branch. I am not sure
why, but the issue (bash with readline crash) seems to disappear.
Could you please try?
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mintty crashes on Windows 7
2022-05-08 11:08 ` Takashi Yano
@ 2022-05-08 11:22 ` Orgad Shaneh
0 siblings, 0 replies; 23+ messages in thread
From: Orgad Shaneh @ 2022-05-08 11:22 UTC (permalink / raw)
To: Takashi Yano; +Cc: cygwin, Johannes Schindelin
On Sun, May 8, 2022 at 2:09 PM Takashi Yano <takashi.yano@nifty.ne.jp> wrote:
> I have pushed two patches to cygwin-3_3-branch. I am not sure
> why, but the issue (bash with readline crash) seems to disappear.
>
> Could you please try?
It no longer crashes with these fixes.
Thanks!
- Orgad
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2022-05-08 11:22 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-03 11:47 mintty crashes on Windows 7 Orgad Shaneh
2022-05-03 15:23 ` Takashi Yano
2022-05-03 15:52 ` Orgad Shaneh
2022-05-03 16:10 ` Takashi Yano
2022-05-04 9:33 ` Orgad Shaneh
2022-05-04 9:46 ` Orgad Shaneh
2022-05-04 11:16 ` Takashi Yano
2022-05-04 13:27 ` Orgad Shaneh
2022-05-05 1:20 ` Takashi Yano
2022-05-05 1:27 ` Takashi Yano
2022-05-05 1:59 ` Takashi Yano
2022-05-05 3:33 ` Takashi Yano
2022-05-05 4:41 ` Takashi Yano
2022-05-05 6:44 ` Takashi Yano
2022-05-05 22:48 ` Takashi Yano
2022-05-06 14:05 ` Orgad Shaneh
2022-05-06 17:22 ` Brian Inglis
2022-05-06 19:02 ` Takashi Yano
2022-05-06 19:16 ` Johannes Schindelin
2022-05-06 20:13 ` Takashi Yano
2022-05-07 0:20 ` Takashi Yano
2022-05-08 11:08 ` Takashi Yano
2022-05-08 11:22 ` Orgad Shaneh
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).