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 on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Profile the attached solution with heap shot. A file is read into unused byte arrays 5 times. Two of those byte arrays are shown by heap shot to still be in memory even after the forced garbage collection (Heap Shot shows 80+ MB of Byte in memory).
Curiously, the null check early return in the constructor of Class1 is necessary for this leak to occur. Without it, Heap Shot shows no evidence of a leak.
I was wondering if maybe this is just a symptom of caching, however, it appears the file is in memory twice. If it were being cached, I would only expect it once.
Created attachment 9956 [details]
Was your original project different? The attached project was not set for heapshot when I tried it (maybe it's a bit diffferent)
Once I enabled it Heapshot reports a `Total memory` of 42MB when I try this on a (32bits) device.
Can you tell us:
* which type of device you used ?
* which exact version of Xamarin.iOS (and other software) was used ? (from XS about dialog)
I zipped the same solution I saw the behavior with, but maybe I zipped it before I enabled the right settings for device builds.
There seems to be some randomness. Running this a few more times this morning I have seen ~0, ~40 and ~80 MB on an iPad 3. I would expect to always see 0.
I'm using an iPad 3, Xamarin.iOS 8.6.20, XCode 6.1.1, and mono 3.12.0 on OS X 10.9.5
Sorry, that's Xamarin.iOS 184.108.40.206
@Randall thanks for the extra information.
@Rodrigo any clue why one (or more) of those buffer never gets collected ? (it's not been random to me, always a single instance keeps being reported).
Yes, conservative stack scanning explains this.
So it explains what you've been experiencing. It's the expected behavior of GC with conservative stack scanning.
I got that, but the expected behavior isn't very desirable at all. How do we prevent the byte array from leaking?
It will eventually be collected when the related stack frame is replaced with other values.
The fix is to observe memory consumption over time and not over a single operation to find meaningful issues.
We have in our roadmap to address this issue in the future.