many cygwin shells/tools (tcsh, fish, bash, and zsh) crashing STATUS_ACCESS_VIOLATION

[Mark Geisert]

Replying to myself, ahem...

Mark Geisert wrote:
> Hi David,
> 
> David Dyck via Cygwin wrote:
>> On Tue, Aug 10, 2021 at 10:56 AM Brian Inglis  wrote:
>>> Apparently that Windows Version is for the Windows 11 Preview.
>>> That appears to be an alpha quality product, from bug fix announcements.
>>> I didn't find anything much useful from MS or articles only features.
>>> You might want to reach out for help via the Windows Feedback Hub,
>>> and/or MS App Assure re compatibility if your org has 150+ licenses.
>>
>> I'm interested in what could be going wrong that would cause only some
>> cygwin programs to fail.
>>
>> I'd be happy to report the issue via Windows Feedback if I could point
>> to something specific.
[...]
> You could try downgrading ncurses via Cygwin setup.  Best case: things work. Worst 
> case: things break but at a different address within the DLL.

On another branch of this thread David reported that downgrading worked.  We still 
don't know what the issue with current ncurses is, so I did try the following:

> Another tack could be for somebody *on a working system* install the debuginfo for 
> ncurses, figure out the exception's address *in the ncurses installed locally*, 
> run 'more' under gdb after setting a breakpoint at that address.  Poke around to 
> see what ncurses is doing in that area.  Maybe it's acting on a Windows result 
> that's busted on the Windows preview.  Or something else.  Good luck with this 
> route :-/.

Here's the gdb session from my own Windows 10 machine...

/usr/lib/debug/usr/bin gdb -q more.exe
Reading symbols from more.exe...
(No debugging symbols found in more.exe)
(gdb) b main
No symbol table is loaded.  Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (main) pending.
(gdb) b ncwrap_cur_term   <-- I deduced the faulting func using exception address
No symbol table is loaded.  Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (ncwrap_cur_term) pending.
(gdb) r
Starting program: /usr/bin/more.exe
[New Thread 12052.0x388]
[New Thread 12052.0x2750]
[New Thread 12052.0x2d08]
[New Thread 12052.0x275c]

Thread 1 "more" hit Breakpoint 2, ncwrap_cur_term ()
     at /usr/src/debug/ncurses-6.1-1.20190727/ncurses/tinfo/lib_cur_term.c:68
68          return NCURSES_SP_NAME(_nc_get_cur_term) (CURRENT_SCREEN);
(gdb) disassem ncwrap_cur_term
Dump of assembler code for function ncwrap_cur_term:
=> 0x00000003cc658a30 <+0>:     mov    0x18a39(%rip),%rax        # 0x3cc671470 
<.refptr.SP>
    0x00000003cc658a37 <+7>:     mov    (%rax),%rcx
    0x00000003cc658a3a <+10>:    jmp    0x3cc658a10 <_nc_get_cur_term_sp>
End of assembler dump.
(gdb) list
63
64      NCURSES_EXPORT(TERMINAL *)
65      NCURSES_PUBLIC_VAR(cur_term) (void)
66      {
67      #if NCURSES_SP_FUNCS
68          return NCURSES_SP_NAME(_nc_get_cur_term) (CURRENT_SCREEN);
69      #else
70          return NCURSES_SP_NAME(_nc_get_cur_term) (NCURSES_SP_ARG);
71      #endif
72      }
(gdb) bt
#0  ncwrap_cur_term ()
     at /usr/src/debug/ncurses-6.1-1.20190727/ncurses/tinfo/lib_cur_term.c:68
#1  0x00000003cc65ac7c in _nc_setupterm (tname=0x80003a055 "xterm", Filedes=1,
     errret=0xffffc4e4, reuse=0)
     at /usr/src/debug/ncurses-6.1-1.20190727/ncurses/tinfo/lib_setup.c:646
#2  0x00000001004057fd in ?? ()
#3  0x0000000180049cbb in dll_crt0_1 () at /oss/src/winsup/cygwin/dcrt0.cc:1037
#4  0x0000000180047736 in _cygtls::call2 (this=0xffffce00,
     func=0x180048c40 <dll_crt0_1(void*)>, arg=0x0, buf=buf@entry=0xffffcdf0)
     at /oss/src/winsup/cygwin/cygtls.cc:40
#5  0x00000001800477e4 in _cygtls::call (func=<optimized out>,
     arg=<optimized out>) at /usr/include/w32api/psdk_inc/intrin-impl.h:838
#6  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)

So the fault happens during ncurses initialization.  As to why this happens on a 
Win 11 Preview and evidently not on Win 10, I have no idea.  The code is trying to 
get the current value of 'cur_term', but that's not a local variable and I don't 
grok what the machine instructions are doing.  The fault address is the 2nd mov, 
so I believe the fault occurred during the 1st mov.

That is all the help/damage I can do at this point.
Cheers,

..mark