We encountered a mysterious memory leak that when triggered would start using up the memory non-stop, and that if you didn't attention it would render the computer unusable forcing the user to do a hard shutdown. In around 15-30 seconds used up all RAM Memory available (in computers with 32 GBs of RAM).
We had a really hard time troubleshooting this issue, until we realized it was due to the XamLinearGauge control.
We had a custom control using the XamLinearGauge, we were binding the MinimumValue and MaximumValue, something similar to this:
<ig:XamLinearGauge MinimumValue="{Binding MinValue}" MaximumValue="{Binding MaxValue}" />
It seems there is a bug inside the XamLinearGauge, if you use a MinimumValue too close to the MaximumValue it fails and creates, if you are lucky, a System.OutOfMemory Exception, and otherwise freeze the computer by continuously requesting more memory.
If you use values like:
MinimumValue="0.649999" MaximumValue="0.650001"
On the Designer you get a System.OutMemoryException. If you are binding the values of those properties, your application gets trapped in a requesting memory loop.
We found that the threshold for the error was 0.5, if you used values separate by less than 0.5 it fails.
From our troubleshooting, we believe the control gets trapped in some sort of loop where it allocates more and more memory for the ticks. We saw with a memory profiler a huge sparse List<Tuple<double,double>> object that we were not allocating.
We had to remove the control an do our own implementation. I believe this a bug of the control.
The fix for development issue 217357 is available in the latest service release which can be downloaded from the My Keys and Downloads page.
Great! Thanks!
Hi Dzyann,
Thanks for notifying us of this. I reproduced the memory exception. This is caused by some code we have which rounds the gauge labels. The space between the min and max is so small that rounding is restricting the label creation from iterating properly so the loop just keeps going forever, continually adding labels until it runs out of memory.
Presumably we round the label values in order to keep the labels concise and readable but looks like we'll have to add some logic for really close together min & maxes. I have logged a development issue for this in our internal tracking system with an ID of 217357. I have also created a private support case for you and linked it to the development issue so that you may track its status. The case number is CAS-171692-H5C3N4 and you can view it here.