mintty leaks handles when enable_pcon=true (ConPTY)

[Hakkin]

I recently reinstalled Windows 10 and had to re-setup my MSYS2 environment, and I noticed one of the scripts I had running in a loop was leaking a lot of handles to mintty. The culprit seems to be calling jq, each time it's called the handle count in Task Manager increases by one. This seems to be caused by the ConPTY support that was enabled by default in late 2022, I suppose the version I was using before defaulted to it off. Setting MSYS=disable_pcon fixes this for me, but obviously it brings back all the issues that ConPTY tries to fix.

You should be able to replicate this by installing jq (the one in the mingw packages works) and then repeatedly calling jq while watching the handle count of the main mintty process in Task Manager or Process Explorer.

Checking the open handles in Process Explorer, the leaking handles seem to be from \Device\NamedPipe\msys-dd50a72ab4668b33-pty1-from-master-nat

[Biswa96]

@tyan0 Could you provide any information about this issue?

[dscho]

@Hakkin could you dig a bit deeper into this? I tried the same thing with a dummy C program:

#include <stdio.h>

int main(int argc, char **argv)
{
	printf("Hello\n");
	return 0;
}

I was not able to find any information about handle count in the Task Manager, but in Process Explorer. The curious thing: the Handle Count did not change for this C program.

Even more curious, when I tried the same with jq, Process Explorer did show an increase of the Handle Count but when I then tried to figure out which resources those handles correspond to, using Sysinternals' Handle tool, I failed to see any difference... The same set of handles was printed by that tool before and after launching jq, even with the -a option.

Maybe you can find out more?

[Hakkin]

@dscho
In Task Manager you can show the handle count in the "Details" tab, you can right click the top header and choose "Select columns", then check "Handles".
It does seem to be something specific about jq, I wasn't able to replicate it using the few other Windows console programs I tried, though there might be other tools that are affected as well.
Using the Handle's tool with the -a and -p <PID> flags I was able to get take a before/after diff when running the jq tool 6 times:

67c67
<   10C: <Unknown type> \BaseNamedObjects\msys-2.0S5-dd50a72ab4668b33\shared.5
---
>   10C: Section       \BaseNamedObjects\msys-2.0S5-dd50a72ab4668b33\shared.5
69c69
<   114: <Unknown type> \BaseNamedObjects\msys-2.0S5-dd50a72ab4668b33\cygpid.16111
---
>   114: Section       \BaseNamedObjects\msys-2.0S5-dd50a72ab4668b33\cygpid.16111
73c73
<   124: <Unknown type> \BaseNamedObjects\msys-2.0S5-dd50a72ab4668b33\S-1-5-21-4213700229-1965502778-2643843408-1001.1
---
>   124: Section       \BaseNamedObjects\msys-2.0S5-dd50a72ab4668b33\S-1-5-21-4213700229-1965502778-2643843408-1001.1
177c177
<   2C4: <Unknown type> \Windows\Theme2279322060
---
>   2C4: Section       \Windows\Theme2279322060
181c181
<   2D4: <Unknown type> \Sessions\1\Windows\Theme1026443161
---
>   2D4: Section       \Sessions\1\Windows\Theme1026443161
207c207
<   33C: <Unknown type> \Sessions\1\BaseNamedObjects\windows_shell_global_counters
---
>   33C: Section       \Sessions\1\BaseNamedObjects\windows_shell_global_counters
243,244c243,244
<   3CC: <Unknown type>
<   3D0: <Unknown type>
---
>   3CC: Timer
>   3D0: Timer
279c279
<   460: <Unknown type> \BaseNamedObjects\msys-2.0S5-dd50a72ab4668b33\cygpid.16112
---
>   460: Section       \BaseNamedObjects\msys-2.0S5-dd50a72ab4668b33\cygpid.16112
292c292
<   4A0: <Unknown type> \BaseNamedObjects\__ComCatalogCache__
---
>   4A0: Section       \BaseNamedObjects\__ComCatalogCache__
295c295
<   4AC: <Unknown type> \BaseNamedObjects\__ComCatalogCache__
---
>   4AC: Section       \BaseNamedObjects\__ComCatalogCache__
301c301
<   4C4: <Unknown type>
---
>   4C4: Timer
330,331c330,331
<   540: <Unknown type> \Sessions\1\BaseNamedObjects\2138HWNDInterface:141142
<   544: <Unknown type> \Sessions\1\BaseNamedObjects\2138HWNDInterface:141142
---
>   540: Section       \Sessions\1\BaseNamedObjects\2138HWNDInterface:141142
>   544: Section       \Sessions\1\BaseNamedObjects\2138HWNDInterface:141142
334a335
>   554: Semaphore
337,339c338,348
<   560: <Unknown type>
<   570: <Unknown type>
<   5C4: Semaphore
---
>   560: Timer
>   570: Timer
>   580: File          \Device\NamedPipe\msys-dd50a72ab4668b33-pty3-from-master-nat
>   5C8: File          \Device\NamedPipe\msys-dd50a72ab4668b33-pty3-from-master-nat
>   5F0: Event
>   608: <Unknown type>
>   618: Thread        mintty.exe(8504): 11904
>   620: File          \Device\NamedPipe\msys-dd50a72ab4668b33-pty3-from-master-nat
>   624: File          \Device\NamedPipe\msys-dd50a72ab4668b33-pty3-from-master-nat
>   650: File          \Device\NamedPipe\msys-dd50a72ab4668b33-pty3-from-master-nat
>   720: File          \Device\NamedPipe\msys-dd50a72ab4668b33-pty3-from-master-nat

You can see the leaking pipes at the bottom.

[Hakkin]

I tried the same thing with a dummy C program:

Interestingly, I just attempted this with your sample C program and could reproduce the issue with it.

$ which gcc
/ucrt64/bin/gcc

$ gcc --version
gcc.exe (Rev4, Built by MSYS2 project) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc main.c

$ ls
a.exe  main.c

$ ./a.exe
Hello

$ ./a.exe
Hello

$ ./a.exe
Hello

results in 3 leaked pipes.

<   5F0: Semaphore
---
>   568: File          \Device\NamedPipe\msys-dd50a72ab4668b33-pty3-from-master-nat
>   590: File          \Device\NamedPipe\msys-dd50a72ab4668b33-pty3-from-master-nat
>   674: File          \Device\NamedPipe\msys-dd50a72ab4668b33-pty3-from-master-nat
>   6BC: Semaphore

[tyan0]

Thanks for finding this issue. I found a bug in pty code (in fhandler_pty_slave::transfer_input()). I'll fix that ASAP.

[tyan0]

I have pushed the patch just now.
https://cygwin.com/pipermail/cygwin-patches/2024q1/012622.html

[dscho]

@Hakkin how urgent is this for you? If it is very urgent, please cherry-pick the commit onto msys2-3.4.10 and open a PR. If it has time to wait until we switch to v3.5.0, then we already have the commit in msys2-3.5.0.

[Hakkin]

No rush for me, I can wait until 3.5.0.

[Hakkin]

Remembered this issue and just got around to testing it again on the latest version, seems this has been fixed now, so I hope it's fine to close this issue. Feel free to reopen it if needed.