From: Alexey Izbyshev <izbyshev@ispras.ru>
To: Takashi Yano <takashi.yano@nifty.ne.jp>
Cc: cygwin@cygwin.com
Subject: Re: Deadlock of the process tree when running make
Date: Sat, 09 Apr 2022 23:26:51 +0300 [thread overview]
Message-ID: <7204ed0aa2d6b3fcfb239010e6b67646@ispras.ru> (raw)
In-Reply-To: <afad32070411d6d94d5d94da90478af4@ispras.ru>
On 2022-04-09 22:35, Alexey Izbyshev wrote:
> On 2022-04-09 20:54, Takashi Yano wrote:
>> Thanks for checking. This seems to be normal. Then, I cannot
>> understand why the ClosePseudoConsole() call is blocked...
>>
>> The document by Microsoft mentions the blocking conditions of
>> ClosePseudoConsole():
>> https://docs.microsoft.com/en-us/windows/console/closepseudoconsole
>> however, the thread above is draining the channel.
>
> I've decided to check what object ClosePseudoConsole() waits for. The
> wait happens inside unexported KERNELBASE!_ClosePseudoConsoleMembers
> function. Here is the relevant part:
>
> 76589fb5 8b4e08 mov ecx,dword ptr [esi+8]
> 76589fb8 e8c2fdffff call KERNELBASE!_HandleIsValid (76589d7f)
> 76589fbd 84c0 test al,al
> 76589fbf 7456 je
> KERNELBASE!_ClosePseudoConsoleMembers+0x89 (7658a017)
> 76589fc1 8d45fc lea eax,[ebp-4]
> 76589fc4 895dfc mov dword ptr [ebp-4],ebx
> 76589fc7 50 push eax
> 76589fc8 51 push ecx
> 76589fc9 e8c23ef5ff call KERNELBASE!GetExitCodeProcess
> (764dde90)
> 76589fce 85c0 test eax,eax
> 76589fd0 7414 je
> KERNELBASE!_ClosePseudoConsoleMembers+0x58 (76589fe6)
> 76589fd2 817dfc03010000 cmp dword ptr [ebp-4],103h
> 76589fd9 750b jne
> KERNELBASE!_ClosePseudoConsoleMembers+0x58 (76589fe6)
> 76589fdb 53 push ebx
> 76589fdc 6aff push 0FFFFFFFFh
> 76589fde ff7608 push dword ptr [esi+8]
> 76589fe1 e8ba74f6ff call KERNELBASE!WaitForSingleObjectEx
> (764f14a0)
>
> "esi" is the argument of ClosePseudoConsole(), so the first mov
> dereferences it with an offset and loads a process handle. Then, if
> this handle is valid, it calls GetExitCodeProcess(), and if it
> succeeds and returns STILL_ACTIVE, it waits for that process.
>
> I've checked that hanging bash process has only 3 process handles: for
> itself, for dead javac, and for conhost.exe. So obviously it waits for
> the latter to terminate. (After I did all this, I realized there was
> much easier way to get this result via "Analyze wait chain" feature of
> Task Manager).
>
> Unfortunately, I don't know anything about Windows consoles, but just
> in case I also checked what 5 threads of conhost.exe are waiting for:
>
> 1. Tries to enter a critical section (Task Manager claims it waits for
> thread 4, so probably the latter owns it).
> 2. Waits on a handle for "pty1-from-master-nat" named pipe.
> 3. Waits for an anonymous event.
> 4. Waits on a handle for "\Device\ConDrv" (in DeviceIoControl()).
> 5. Blocked in GetMessageW().
>
> It's also worth of note that this conhost.exe seems to be the only one
> related to the Cygwin process tree (as well as the only related
> non-Cygwin process). All other conhost.exe processes were created
> before I started my stress test.
>
> My guess is that this conhost.exe was created for a native app started
> from a Cygwin process. Could it be some race condition/bug that
> prevented conhost.exe from terminating once the native process
> (probably javac?) died?
>
A few more things that might be important:
* Clarification: thread 2 of conhost.exe waits in KernelBase!ReadFile().
* In the assembly part I omitted, before waiting on the conhost process,
_ClosePseudoConsoleMembers() closes the handle obtained from "dword ptr
[esi]", i.e. "hWritePipe" member of HPCON_INTERNAL struct.
Alexey
next prev parent reply other threads:[~2022-04-09 20:26 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-07 21:53 Alexey Izbyshev
2022-04-07 23:54 ` Brian Inglis
2022-04-08 8:42 ` Alexey Izbyshev
2022-04-08 17:04 ` Brian Inglis
2022-04-11 13:27 ` Alexey Izbyshev
2022-04-09 10:17 ` Takashi Yano
2022-04-09 11:00 ` Alexey Izbyshev
2022-04-09 11:02 ` Alexey Izbyshev
2022-04-09 11:46 ` Takashi Yano
2022-04-09 16:07 ` Alexey Izbyshev
2022-04-09 16:57 ` Takashi Yano
2022-04-09 17:23 ` Alexey Izbyshev
2022-04-09 17:54 ` Takashi Yano
2022-04-09 19:35 ` Alexey Izbyshev
2022-04-09 20:26 ` Alexey Izbyshev [this message]
2022-04-10 7:34 ` Takashi Yano
2022-04-10 12:13 ` Alexey Izbyshev
2022-04-10 20:49 ` Alexey Izbyshev
2022-04-11 8:35 ` Takashi Yano
2022-04-11 10:10 ` Alexey Izbyshev
2022-04-13 16:48 ` Alexey Izbyshev
2022-04-13 17:22 ` Takashi Yano
2022-04-13 17:27 ` Alexey Izbyshev
2022-04-13 23:17 ` Alexey Izbyshev
2022-04-16 9:39 ` Takashi Yano
2022-04-16 13:21 ` Alexey Izbyshev
2022-04-27 11:22 ` Takashi Yano
2022-04-27 12:19 ` Alexey Izbyshev
2022-04-11 5:23 ` Jeremy Drake
2022-04-11 8:36 ` Takashi Yano
2022-04-11 15:28 ` Alexey Izbyshev
2022-04-11 17:02 ` Jeremy Drake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7204ed0aa2d6b3fcfb239010e6b67646@ispras.ru \
--to=izbyshev@ispras.ru \
--cc=cygwin@cygwin.com \
--cc=takashi.yano@nifty.ne.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).