Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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 45988 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
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
Created attachment 18242 [details]
Xamarin Profiler - object creation stack trace
We are using Mono 4.4.2 under Debian Linux on a single board computer which is part of a large embedded product. We are using Nginx/fastcgi to provide a web interface to this product.
Http POST requests are used to upload files of various sizes. The file itself is irrelevant and anonymous. Fastcgi hands off the request to a System.Threading.ThreadPool worker. We have now distilled our code to do nothing beyond Fastcgi, yet we continue to see a memory leak per worker thread per file upload request. Eventually the system runs out of memory. Each worker thread which has been tasked to handle the upload request (controlled by the ThreadPool class) has a leak of System.Bytes, the size of which exactly matches the size of the file to be uploaded - even though the upload itself is commented out and doesn't actually happen.
Using the Xamarin profiler (thanks) I can now see where this is happening. (Image attached).
The stack trace of the origin of each of the leaked objects points to:
ResponderRequest::OnInputDataReceived(Request sender, DataReceivedArgs args). Following this trace in the the actual fastcgi code in Visual Studio, I can see that this method allocates a byte array whose size corresponds to "CONTENT_LENGTH". There is also a copy function. My environment is not geared up to build and debug fastcgi itself.
In the short term and as a workaround, we are going to uses PHP to handle the uploads (probably more efficient anyway).
That is the place where the buffer is allocated, the issue is not likely there, since the array is merely allocated there. The issue is that for this memory to be released, it needs to be be removed, this takes place in Connection.cs/RemoveRequest, which looks like it is invoked from EndRequest.
Perhaps your requests are not completing?