Created attachment 12065 [details]
socket leak testbed
HttpListener appears to be leaking sockets under heavy load. This shows up as an ever increasing number of 'can't identify protocol' entries from calling lsof | grep <pid>. Eventually, the process will run out of sockets completely, with them all being taken up by leaked sockets, which are not correctly closed by mono.
I've finally managed to create a minimal test bed to reproduce this problem, which I have attached to this report.
To use this testbed:
mono --debug server.exe
mono --debug client.exe
wait for around 10 seconds in the client shell, then press return to exit.
ps -A | grep mono
<locate server.exe pid>
lsof | grep <pid>
mono 9160 root mem REG 8,1 6144 1576189 /root/socketDebug/server.exe
mono 9160 root 0u CHR 136,0 0t0 3 /dev/pts/0
mono 9160 root 1u CHR 136,0 0t0 3 /dev/pts/0
mono 9160 root 2u CHR 136,0 0t0 3 /dev/pts/0
mono 9160 root 3u IPv4 518804426 0t0 TCP localhost:webcache (LISTEN)
mono 9160 root 4u REG 0,9 0 3674 anon_inode
mono 9160 root 5u sock 0,6 0t0 518805101 can't identify protocol
mono 9160 root 6u sock 0,6 0t0 518805103 can't identify protocol
Run the client again and watch the list of leaked sockets increase.
I have tried to look into the cause of this, and will continue to do so, but so far I haven't been able to identify the exact source of the leaks.