SciChart WPF 2D Charts > Troubleshooting > Debugging Memory Leaks
Debugging Memory Leaks

From time to time our customers report memory leaks in their applications which use SciChart. Sometimes memory leaks are caused by customer code, and sometimes by SciChart code.

Usually memory leaks caused by SciChart are resolved within a few days and a fix is pushed to our Nightly Build feed, as we consider these to be high priority issues.

In this article we are going to talk about the approach we take to diagnosing memory leaks and what we will need from you to solve these kinds of issues quickly.

Freeing Memory Held by SciChart

In order to free memory from SciChart you don't need to do anything special.

The SciChartSurface control itself implements the Dispose & Finalizer patterns, and automatically disposes unmanaged resources held once the SciChartSurface goes out of scope (no references remain to the SciChartSurface ).

The largest objects are the DataSeries which hold the actual X,Y data. DataSeries do not implement the IDisposable interface, so, once these go out of scope, memory should be freed shortly after by the garbage collector.

If you wish to relieve pressure from the GC you can explicitly call SciChartSurface.Dispose(), or DataSeries.Clear but in most cases, this should not be necessary.

Checklist: When You discover a memory leak

If you think memory is leaking in your application, take a moment to run through this checklist before contacting support.

  1. Is memory actually leaking? Or is it just rising?
  2. What is causing the memory leak? Do some memory profiling (using SciTech Memory Profiler, or dotMemory or ANTS Profiler)
  3. Isolate code which causes the leak.
  4. Send this code to us (include profiling results if you have them)

Step 1: Is Memory Leaking?

When discovering memory is rising in your applcation, do some quick work to see if memory is leaking or if it is just rising.

For example, if you are appending lots of points to the chart you can expect the memory to rise. You can also expect that memory to be reclaimed when the SciChartSurface / DataSeries holding the data is no longer referencing by anything in your application.

You can check for a memory leak by doing a repeated operation again and again and seeing if the memory continues to rise, or is reclaimed.

You can force a Garbage Collection operation by using this code: How to force a Garbage Collection.

Force Garbage collection
Copy Code
// Use this to test if the memory is leaking after you null
// all references to a SciChartSurface


Step 2: What is causing the memory leak?

If you are now certain that memory is leaking, the next step is to determine what is causing the memory leak. To do this, you can use a memory profiler. Memory profilers include:

In this video at 1m44s we show how to use a memory profiler to identify the shortest path to GC Roots (what is holding the memory) by getting a snapshot in dotTrace and exploring the shortest path to GC Roots to identify what is holding on to the memory.

This can reveal something interesting about your application. Maybe it is something in your code which is holding on to the memory? Maybe it is something in ours.

Typical memory leak culprits include:

  • Static Dictionaries, Lists or Variables that are used and never cleared.
  • Event handler subscriptions which are never unsubscribed.
  • Deadlocked threads or blocked finalisers.
  • Bugs in the .NET Framework or WPF (yes they do happen)

Step 3: Isolate code which causes the leak

Say you have performed the steps above and you're pretty sure that there is a memory leak when SciChart is used in a particular way. Now, isolate the code which causes the leak and send it to us.

Even if you are not a supported customer we will endevour to look into memory leaks as a matter of urgency. Hopefully, we can provide a fix quickly and get you back to work as soon as possible!



See Also