Re: deadlock on console mutex in gdb

[David McFarland <corngood@gmail.com>]

David McFarland <corngood@gmail.com> writes:

> I've also been hitting another console related deadlock, even when
> there's no debugger involved:

So I tried to fix this one by doing this:

From a66d334577217f178a841f006e295a9b8e50c677 Mon Sep 17 00:00:00 2001
From: David McFarland <corngood@gmail.com>
Date: Thu, 23 Dec 2021 16:12:47 -0400
Subject: [PATCH] tty: create attach_mutex in static constructor

---
 winsup/cygwin/fhandler_tty.cc | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
index c425c158b..36262dbb9 100644
--- a/winsup/cygwin/fhandler_tty.cc
+++ b/winsup/cygwin/fhandler_tty.cc
@@ -58,7 +58,7 @@ struct pipe_reply {
 };
 
 /* Mutex for AttachConsole()/FreeConsole() */
-HANDLE attach_mutex;
+HANDLE attach_mutex = CreateMutex (&sec_none, FALSE, NULL);
 
 bool __acquire_attach_mutex (const char *fn, int ln, DWORD t)
 {
@@ -77,8 +77,6 @@ void __release_attach_mutex (const char *fn, int ln)
   assert(r);
 }
 
-static LONG master_cnt = 0;
-
 inline static bool pcon_pid_alive (DWORD pid);
 
 DWORD
@@ -2122,8 +2120,6 @@ fhandler_pty_master::close ()
 	  master_fwd_thread->terminate_thread ();
 	}
     }
-  if (InterlockedDecrement (&master_cnt) == 0)
-    CloseHandle (attach_mutex);
 
   /* Check if the last master handle has been closed.  If so, set
      input_available_event to wake up potentially waiting slaves. */
@@ -3002,9 +2998,6 @@ fhandler_pty_master::setup ()
   if (!(pcon_mutex = CreateMutex (&sa, FALSE, buf)))
     goto err;
 
-  if (InterlockedIncrement (&master_cnt) == 1)
-    attach_mutex = CreateMutex (&sa, FALSE, NULL);
-
   /* Create master control pipe which allows the master to duplicate
      the pty pipe handles to processes which deserve it. */
   __small_sprintf (buf, "\\\\.\\pipe\\cygwin-%S-pty%d-master-ctl",
-- 
2.32.0


Unfortunately I seem to have another deadlock when using this patch.
With the above patch applied, if I just open bash and hold down ^C, it
will deadlock pretty quickly.  It's possible this is an exiting problem
that isn't normally noticed because bash never opens the PT.

The threads involved are:

Thread 1 (Thread 14700.0x3804):
#0  0x00007ffca30ed8c4 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x00007ffca0dbcb20 in WaitForMultipleObjectsEx () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
#2  0x00007ffca0dbca1e in WaitForMultipleObjects () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
#3  0x000000018012f89e in select_stuff::wait (this=0xffffb4b0, readfds=0xffffb720, writefds=0xffffb620, exceptfds=0xffffb630, us=-1) at ../../../../winsup/cygwin/select.cc:419
#4  0x000000018012ee17 in select (maxfds=1, readfds=0xffffb720, writefds=0xffffb620, exceptfds=0xffffb630, us=-1) at ../../../../winsup/cygwin/select.cc:192
#5  0x000000018012e967 in pselect (maxfds=1, readfds=0xffffb720, writefds=0x0, exceptfds=0x0, to=0x0, set=0x3fd45b890 <cygreadline7!_rl_orig_sigset>) at ../../../../winsup/cygwin/select.cc:120
#6  0x00000001801a761b in _sigfe () at sigfe.s:37
#7  0x00000003fd43e698 in rl_getc () from /usr/bin/cygreadline7.dll
#8  0x00000003fd43eecc in rl_read_key () from /usr/bin/cygreadline7.dll
#9  0x00000003fd421ef3 in readline_internal_char () from /usr/bin/cygreadline7.dll
#10 0x00000003fd422905 in readline () from /usr/bin/cygreadline7.dll
#11 0x000000010040265d in reader_loop ()
#12 0x0000000100404723 in decode_prompt_string ()
#13 0x00000001004074ac in read_secondary_line ()
#14 0x000000010040aa97 in yyparse ()
#15 0x0000000100401b92 in parse_command ()
#16 0x0000000100401c96 in read_command ()
#17 0x0000000100401ec4 in reader_loop ()
#18 0x000000010047c3ba in main ()

Thread 6 (Thread 14700.0x1e9c):
#0  0x00007ffca30ecdf4 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x00007ffca0d91a5e in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
#2  0x00000001800c13b8 in __acquire_attach_mutex (fn=0x1802c59b8 <fhandler_console::MAX_WRITE_CHARS+1076> "virtual int fhandler_console::tcflush(int)", ln=1574, t=4294967295) at ../../../../winsup/cygwin/fhandler_tty.cc:67
#3  0x0000000180074fa7 in fhandler_console::tcflush (this=0x1803b6760, queue=0) at ../../../../winsup/cygwin/fhandler_console.cc:1574
#4  0x00000001800c025c in fhandler_termios::sigflush (this=0x1803b6760) at ../../../../winsup/cygwin/fhandler_termios.cc:503
#5  0x00000001800bec92 in tty_min::kill_pgrp (this=0x180000000, sig=2) at ../../../../winsup/cygwin/fhandler_termios.cc:131
#6  0x0000000180070a62 in fhandler_console::cons_master_thread (p=0x26acb70, ttyp=0x180000000) at ../../../../winsup/cygwin/fhandler_console.cc:253
#7  0x0000000180070555 in cons_master_thread (arg=0x1803b63e0) at ../../../../winsup/cygwin/fhandler_console.cc:173
#8  0x000000018004657c in cygthread::callfunc (this=0x180278278 <threads+88>, issimplestub=false) at ../../../../winsup/cygwin/cygthread.cc:48
#9  0x0000000180046724 in cygthread::stub (arg=0x180278278 <threads+88>) at ../../../../winsup/cygwin/cygthread.cc:91
#10 0x00000001800473b6 in _cygtls::call2 (this=0x26ace00, func=0x180046582 <cygthread::stub(void*)>, arg=0x180278278 <threads+88>, buf=0x26acce0) at ../../../../winsup/cygwin/cygtls.cc:55
#11 0x000000018004735b in _cygtls::call (func=0x180046582 <cygthread::stub(void*)>, arg=0x180278278 <threads+88>) at ../../../../winsup/cygwin/cygtls.cc:42
#12 0x00000001800df5b2 in threadfunc_fe (arg=0x180278278 <threads+88>) at ../../../../winsup/cygwin/init.cc:30
#13 0x00007ffca2ae7034 in KERNEL32!BaseThreadInitThunk () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
#14 0x00007ffca30a2651 in ntdll!RtlUserThreadStart () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#15 0x0000000000000000 in ?? ()

Thread 9 (Thread 14700.0x183c):
#0  0x00007ffca30ecdf4 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x00007ffca0d91a5e in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
#2  0x000000018007bb0c in fhandler_console::__acquire_input_mutex (this=0x1803b7420, fn=0x1802e1a20 <cw_std_mask+1536> "int peek_console(select_record*, bool)", ln=1133, ms=4294967295) at ../../../../winsup/cygwin/fhandler_console.cc:3726
#3  0x0000000180131b3f in peek_console (me=0x8000ac530) at ../../../../winsup/cygwin/select.cc:1133
#4  0x0000000180131ce3 in thread_console (arg=0x800075610) at ../../../../winsup/cygwin/select.cc:1173
#5  0x000000018004657c in cygthread::callfunc (this=0x1802782d0 <threads+176>, issimplestub=false) at ../../../../winsup/cygwin/cygthread.cc:48
#6  0x0000000180046724 in cygthread::stub (arg=0x1802782d0 <threads+176>) at ../../../../winsup/cygwin/cygthread.cc:91
#7  0x00000001800473b6 in _cygtls::call2 (this=0x2cbce00, func=0x180046582 <cygthread::stub(void*)>, arg=0x1802782d0 <threads+176>, buf=0x2cbcce0) at ../../../../winsup/cygwin/cygtls.cc:55
#8  0x000000018004735b in _cygtls::call (func=0x180046582 <cygthread::stub(void*)>, arg=0x1802782d0 <threads+176>) at ../../../../winsup/cygwin/cygtls.cc:42
#9  0x00000001800df5b2 in threadfunc_fe (arg=0x1802782d0 <threads+176>) at ../../../../winsup/cygwin/init.cc:30
#10 0x00007ffca2ae7034 in KERNEL32!BaseThreadInitThunk () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
#11 0x00007ffca30a2651 in ntdll!RtlUserThreadStart () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#12 0x0000000000000000 in ?? ()


Thread 6 holds input_mutex from cons_master_thread, and thread 9 holds
attach_mutex from peek_console. Perhaps it would make sense for
peek_console to hold attach_mutex only around the call to
PeekConsoleInputW?