Bug 32014 - HttpListener leaks sockets under load
Summary: HttpListener leaks sockets under load
Status: NEW
Alias: None
Product: Class Libraries
Classification: Mono
Component: System ()
Version: 3.6.0
Hardware: Other Linux
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2015-07-16 07:41 UTC by paul firth
Modified: 2015-07-16 07:41 UTC (History)
1 user (show)

Is this bug a regression?: ---
Last known good build:

socket leak testbed (92.02 KB, application/x-zip-compressed)
2015-07-16 07:41 UTC, paul firth

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report for Bug 32014 on GitHub or Developer Community if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: GitHub Markdown or Developer Community HTML
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:

Description paul firth 2015-07-16 07:41:57 UTC
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

<new shell>

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.

Cheers, Paul.