handle leak, win32 port

[Jeff Hill]

From Carsten Winkler,

It seems to be a handle leak in Channel Access Server V4.13 (current EPICS base)

Create any PVs at softIoc, request it via caget and you see the handle count at softIoc will be
increased by two and won't be freed anymore (without using any EPICS gateway).
If you frequently repeat this procedure you will end up to in a "WINSOCK Error 10055".

This problem occurs at Windows XP with patched EPICS bas 3.14.12.

[Jeff Hill (johill-lanl)]

From Carsten Winkler,

I use the native win32-x86 EPICS base port to windows. My caget doesn't run at a high repetition
rate. The problem also occurs when I use camonitor.

I used camonitor and netstat to check how many tcp circuits are active and in what state they are
in. I called camonitor from a different machine as softIoc.
At the beginning of my test softIoc had 1282 used handles (constant). When I called camonitor I saw
a new TCP connection to port 5064 (via netstat) and an increase of softIoc handles to 1294. Both
values were constant while running camonitor. After stopping camonitor the handle count of softIoc
decreased to 1284 and the TCP connection to port 5064 was still open. After some seconds the TCP
connection to port 5064 has been closed but the handle count still stands by 1284. This two
additional handles will no more be removed and every new camonitor or caget request will add two
more handles until softIoc crashes.

To diagnostic the handle count I use the "Performancemonitor" (perfmon.exe) from MS Windows and the
"Processexplorer" (procexp.exe) from Systeminternals.

I think caget terminates regularly and calls ca_context_destroy to clean up all used channel access
resources.

[Jeff Hill (johill-lanl)]

I am starting to suspect that this has something to do with, not sockets, but instead with the win32 thread handle not being closed, because there are two of them (two threads) for each client. As I recall, with the win32 thread creation API EPICS is using, _beginthreadex, the handle is implicitly closed when the thread function returns, but I will need to investigate in the debugger.

[Kazutaka Nakahara (nakahara)]

I have this exact same problem using the win32-x86 EPICS base port as a bridge to transfer process variables from WinXP to linux.
A python script is run on the linux box that does a caget once a second to retrieve a flag. When the flag is in a certain state, the script does ~80 cagets to grab a bunch of process variable. Attached shows the handle count (on WinXP using Perfmon.exe) while the script is running. When the script is killed, the handle count flatlines but does not decrease.
If the script is run long enough, it will:
1. start giving a winxock error 10055
2. eventually cause a system crash on winXP (blue screen) as the machine eventually runs out of system resources.
I've tried this a couple of times, and both happened without fail each time.

I initially thought this was a tcp socket that's not being closed at the end of a call, but netstat -a does not show any tcp connections accumulating.

[Freddie Akeroyd (freddie-akeroyd)]

I think this could be the same issue referred to at https://epics.anl.gov/tech-talk/2013/msg00857.php - in which case it is now fixed