Re: Deadlock of the process tree when running make

[Alexey Izbyshev <izbyshev@ispras.ru>]

On 2022-04-10 10:34, Takashi Yano wrote:
> On Sat, 09 Apr 2022 23:26:51 +0300
> Thanks for investigating. In the normal case, conhost.exe is terminated
> when hWritePipe is closed.

Thanks for confirming.

> 
> Possibly, the hWritePipe has incorrect handle value.

I've verified that the handle was correct by attaching via gdb to the 
hanging bash and checking that hWritePipe field is now zeroed (which 
happens only in the branch where _HandleIsValid returns true and 
hWritePipe is closed).

I've found something interesting though. I've modeled a similar 
situation on another machine:

1. I've run a native process via bash.
2. I've attached to bash via gdb and set a breakpoint on 
ClosePseudoConsole().
3. I've killed the native process.
4. The breakpoint was hit, and I looked at hWritePipe value.

ProcessHacker shows it as "Unnamed file: \FileSystem\Npfs". Both bash 
and conhost had a single handle with such name, and after I've forcibly 
closed it in the bash process (while it was still suspended by gdb), 
conhost.exe indeed died.

Then I looked at the original hanging tree and found that the hanging 
bash.exe still has a single handle displayed as "Unnamed file: 
\FileSystem\Npfs". I don't know how to check what kernel object it 
refers to, but at least its access rights are the same as for hWritePipe 
that I've seen on another machine, and its handle count is 1. So could 
it be another copy of hWritePipe, e.g. due to some handle leak?

I don't know how to verify whether this suspicious handle in bash.exe is 
paired with "Unnamed file: \FileSystem\Npfs" in conhost.exe, other than 
by forcibly closing it. If I close it and conhost.exe dies, it will 
confirm "the extra handle" theory, but will also prevent further 
investigation with the hanging tree. Do you have any advice?

Thanks,
Alexey