NT 8 B12 mem leak - overnight ~5GB memory

[NinjaTrader_Matthew]

Thanks for sharing your thoughts.

here is my thinking, if a third party door handle can brake the engine in a car than I would not blame the door handle I'd rather try to modify the engine design... I know this is simplification of the issue and the analogy of a car does not fit coding, yet I firmly believe the behavior I am experiencing with NT 8 compare to NT 7 or Multicharts that they are still fundamental issues with NT 8. So if you are able to figure out how on earth the bid/ask can crack you "engine" and fixed that issue than you got a lot closer to rock solid product...

Just my thoughts, kind regards, atata

I understand your point; it is something we debate internally as well. However, to use the same analogy: we have not exposed just a door handle - we have given you access to the pistons, crankshaft, cylinder block, bearings, and the motor mount.

It is a double edge sword - 3rd parties have low-level access to core fundamental data and UI objects which enable them to make very useful and efficient tools, but this level of access comes with the risk that these 3rd parties have the ability to take NinjaTrader to its knees with just one line of code.

We will do what we can within reason to trap issues to prevent NinjaTrader from crashing, but it is just not possible for us to be able to catch these scenarios preemptively. If you can isolate at situation which you are running into, we will be sure to look into it to see what can be done within reason and without unnecessary and far reaching performance impacts

[atata]

Well written response however I believe that was somewhat the case with NT 7? or I am all wrong? I meant here exposing the engine... maybe not the bearings how about the rest?!

Here is a quote from someone from a different forum. I won't mention the name and the forum since I did not ask for permission however you can see frustration and the "faith" in your development process not just me, others who invested real money...

NinjaTurder

So here comes to the time, exactly 1 week after rebuild I have to do NT8 and Windows 10 all over again.

It is so messed up what with random lock ups and crashes. I can't begin to mention how annoyed I am. It is beyond a joke.

I wonder how many times people will get sick of it freezing or crashing quite randomly, for NT to admit Release Candidate 1 is a steaming pile of crap.

So here I sit, $300.00 down because of an early trade (that I shouldn't have taken) and now I have to rebuild my machine.

Typical.

[atata]

Got a over 9GB memory leak again from Sunday night till Monday early morning. Since with the same setup and no issues for over 24 hours... go figure...

Yeah, sure custom code, but what on earth is happening. Sometimes days go by with no issues. The market was quite volatile since so...

atata

[atata]

This is still an issue and what's happened with turning the rocks?

NinjaTrader_Matthew, what's happened to those rocks?
If you suspect as you did previously that the BidAsk custom indicator is the culprit than what has to get changed in the code? Did you find anything?

Also since NT 8 is all "exposed" what are or where are the guidelines documented to avoid memory leaks and or writing a custom code which would crash NT 8?

I've started up NT 8 RC2 this morning around 6 AM EST.
I had to do a shut down just now since mem usage was ~2.8 GBytes.

According to Ray there is a plan to go production in November with a product I can't fully switch over yet because of the bugs...

I can't put a finger on this what would trigger the mem leak. Last week NT 8 after the ugprade was fine running once I believe for over 48 hours without any issues.

Please advise,

atata

[NinjaTrader_Matthew]

I have not been able to definitely reproduce any memory leaks. We are in the process of producing documents to assist 3rd party developers with issues of this nature, although I do not have anything set in stone I can comment on right now.

[NinjaTrader_Matthew]

Since the last time we spoke, we have created a new resource on Using SharpDX Brushes you may wish to review:

http://ninjatrader.com/support/helpGuides/nt8/en-us/index.html?working_with_brushes.htm#AdvancedBrushTypesSharpDX

I am not positive if anything here applies to your code base, but considering the number of custom rendering your indicators are doing, it is likely something in this area. Without being able to reproduce and since this appears to be such a slow "leak," it is hard to say exactly what the cause is.

For example, there was one indicator which called code similar to

SharpDX.Direct2D1.Brush mylineColor = getRegionColor(i);

The mylineColor SharpDX brush was never disposed of. That could certainly be a problem area if many brushes were being created over time.

With that in mind, I'd recommend you go through and make sure you have called .Dispose() on all SharpDX brush objects.

Common objects which would need to be disposed include:

SharpDX.Direct2D1.SolidColorBrush
SharpDX.Direct2D1.Brush
SharpDX.DirectWrite.TextFormat
SharpDX.DirectWrite.TextLayout
SharpDX.Direct2D1.PathGeometry

There could be others depending on resources your indicators are using. In general, if an object implements IDiposable, you should Dispose() of it.

Another potential problem area could be with holding managed objects in reference. While it's not technically a leak, there could be issues if you are not setting a managed object to null to inform the garbage collector that it is safe to release an object from memory.

An example of this was in another one of the indicators you provided; there was code which called

NinjaTrader.Data.Bars    bars    = ChartBars.Bars;

However, this managed bars object was a) never used and b) never marked for garbage collection. Of course simply removing that unused variable could help, but if there are other non-static managed objects you are creating (e.g. using the "new" keyword), it is a good idea to set them to null as soon as you are done.

protected override void OnRender( ChartControl chartControl, ChartScale chartScale )
{
System.Windows.Media.Brush managedBrush   = new SolidColorBrush(Colors.Blue);

// do something with managedBrush  

managedBrush   = null;
}

This would allow the GC to clean up any resources as soon as possible, rather than waiting for the system to run low on memory

[atata]

can't get my head around

Matthew, thanks very much for your response. I will look at the code however I'll also ask sim22 who has published the indicator.

As in the title, in your experience and your team experience what can trigger such a random event? I mean this does not seemed to change since the last few versions ie.: who knows why everything works fine for days than seemingly like a random event the memory leak starts to happen. Anything you and your team has experienced something maybe similar so far even if it seems far fetched or unrelated?

Thanks for your time!

atata

[tulanch]

Interesting to find this post today.... I have a personal use footprint chart working in NT7 without issue. I am now working on a similar personal use footprint indi for nt8 starting with code from futures.io The available bid ask history is awesome!

I am running into a weird memory leak. Things work fine for a number of minutes and then all of a sudden out of nowhere the indi locks up and RAM use spikes. I have not seen any errors in the log file. I have multiple charts with multiple monitors but I know it's this indi that causes it because without it loaded all is well. When this indi locks up the other charts seem to continue to draw, but interaction with them is broke. As an example, today I had a sim order working when it broke - I could not find any way to exit it; not in another chart with active chart trader, not in the super dom and not even from within the control panel. All during this time the T&S display continued to print as did bars on the other charts. I let it continue to run for the remainder of the day. Windows 10 taskmanager listed > 3GB RAM used by the NT8 process group. The only way to end it was to kill task.

I do make use of SharpDX brushes in this. I loop over all the bars ( 900tick, 3 days, ES) and draw different color filled rectangle regions at the price point's bid and ask values. I currently do only 1 dispose outside of the bar loop. Based on this thread it appears you are suggesting to dispose of these as soon as possible, is that correct? Are you saying to create it, use it and dispose on every use even within the bar loop?

I took the single create and dispose outside of the loop thinking multiple new creations and disposes within the loop would be detrimental to performance.

What is the NT8 recommended programming guide using brushes (or any new SharpDX object for that matter) within the overridden OnRender method?

[Sim22]

I will look at the code however I'll also ask sim22 who has published the indicator.
As in the title, in your experience and your team experience what can trigger such a random event?

atata

Hi atata,

As you know NT8 has been a learning curve for all of us. I can't count the number of hours I have tried to fix these 'random events' within my own indicators.

I assume you are referencing the DeltaV2 indicator?

Since publishing the delta indicator I have learned these things:

1. Dispose of all objects after using them. Right away.
2. Check for null references or possible exceptions.
3. Add try-catch statements to all methods where possible.

This will usually take care of start up issues, especially if there are bar loading issues.

What has really helped me is using Visual Studio now with an addin from JetBrains called 'CSharper' that has helped me improve my coding.

Although I use my own heavily modified DeltaV3 I have attempted to update the V2 indicator for you with some extra try-catch statements added. Please see if this improves your performance. Just replace the original DeltaV2 with this one. I very rarely break the 1 GB level using several high computational tick replay indicators using the above methodology.

[Sim22]

I took the single create and dispose outside of the loop thinking multiple new creations and disposes within the loop would be detrimental to performance.

This may not be exactly approved protocol but:

I personally create and dispose of a SharpDx brush right away and I have no problems. If I am using an unmodified DxBrush as I iterate through my indexes in OnRender then I create and dispose after iterating through all the bar indexes (see DeltaV2). If however I want to adjust opacity, tone etc for each bar individually I create and dispose just before using it on every iteration..... that way my brushes 'start' fresh every iteration.

[NinjaTrader_Matthew]

Thanks for posting an update Sim22. I also appreciate you sharing your experience.

[NinjaTrader_Matthew]

Interesting to find this post today.... I have a personal use footprint chart working in NT7 without issue. I am now working on a similar personal use footprint indi for nt8 starting with code from futures.io The available bid ask history is awesome!

I am running into a weird memory leak. Things work fine for a number of minutes and then all of a sudden out of nowhere the indi locks up and RAM use spikes. I have not seen any errors in the log file. I have multiple charts with multiple monitors but I know it's this indi that causes it because without it loaded all is well. When this indi locks up the other charts seem to continue to draw, but interaction with them is broke. As an example, today I had a sim order working when it broke - I could not find any way to exit it; not in another chart with active chart trader, not in the super dom and not even from within the control panel. All during this time the T&S display continued to print as did bars on the other charts. I let it continue to run for the remainder of the day. Windows 10 taskmanager listed > 3GB RAM used by the NT8 process group. The only way to end it was to kill task.

I do make use of SharpDX brushes in this. I loop over all the bars ( 900tick, 3 days, ES) and draw different color filled rectangle regions at the price point's bid and ask values. I currently do only 1 dispose outside of the bar loop. Based on this thread it appears you are suggesting to dispose of these as soon as possible, is that correct? Are you saying to create it, use it and dispose on every use even within the bar loop?

I took the single create and dispose outside of the loop thinking multiple new creations and disposes within the loop would be detrimental to performance.

What is the NT8 recommended programming guide using brushes (or any new SharpDX object for that matter) within the overridden OnRender method?

As long as you are disposing of the brush at some point in the render pass, I think it should be ok. I would tend to agree that creating and disposing of the brush multiple times in the brush would be a performance penalty. Unless you are modifying the brush within the loop, it should be fine to create/dispose of it just before/after the loop.

[tulanch]

success...

I altered my code... did the create before the bar loop and a single dispose of all brushes after, all within the onrender method and the RAM remained steady around 340mb running all day long today.

[NinjaTrader_Matthew]

Thank you for sharing your experience. Glad to hear it is working for you better.