NT8 Chart Crashes on F5 repeat

[QuantKey_Bruce]

In NT8 beta 9, if you load several indicators onto a chart (you can pick almost anything, if there are a number of them) you can hit F5 a few times and deadlock the entire platform. In this example, I randomly picked "R squared", "RSI", "RSS", "RVI", Std. dev." "Stoch RSI", "Stochastics", "Stochastics fast", and "SUM" on a 5 minute chart of ES 03-16. Hit F5 to reload the ninjascript on the chart, and then hit F5 again. You can also hold down F5 such that the key repeats, which repeatedly tries to load the NinjaScript. The chart freezes, and NinjaTrader control center itself is unable to exit cleanly, having to be killed in Task Manager.

Please note - I do not mean to suggest that holding down the F5 key on auto-repeat is normal behavior, that's simply an easy way to get it to fail so you can test the real problem - the actual issue is that indicators take varying amounts of time to refresh (some much longer than these examples, which is why I put a dozen or so on the chart), and there is no indication F5 is working at first, so sometimes the user hits it more than once not sure if it is doing anything, and if they hit it while it is still underway, a deadlock occurs in the multithreading model that requires killing the process to fix.

Thank you for your attention to this!

Bruce DeVault

[QuantKey_Bruce]

An additional note on this - if this happens, and you exit Control Center, the locked chart(s) remain open. If you then right click on NT in the task bar and choose Close, you get a message that there is not enough quota to complete the request, which is a virtual memory error, as if the paging file is not large enough. However, that is not actually the case (unless the memory request is itself incorrect) because the memory usage of NT is low at that time, and I've tried that with up to 64GB of free paging, all of which remained free throughout, confirming that the message itself is errant.

[NinjaTrader_Matthew]

Thanks for the report. We've made some changes internally that are scheduled for the next beta release which I am certain addresses these issues.

I ran your tests on the B9 build and did run into some issues as you reported.

I've re-run those tests using our latest internal build and I can hold F5 as long as I want and it does create any sort of lock up scenario in my testing.

We'll keep a close eye on this test case during our testing for the next build to be sure. You may feel free to retest this and report back when we release the next beta build (tentatively due in 2-3 weeks)

[eDanny]

Hi Matthew, it would be nice to have some indication the chart is recalculating. I really don't like watching a chart sit there when reloading NinjaScript and not know what is happening or if anything is happening at all.

[QuantKey_Bruce]

Thank you Matthew. Does the new internal build also resolve the issue whereby the state can be changed to terminated while OnBarUpdate or other events are still running? In the current multithreading model at least in beta 9 it is possible for an indicator to be destroyed by one thread while OnBarUpdate is still running in another, causing some of its resources to become unavailable and resulting in unexpected exceptions. It does seem like a reasonable expectation that while the OnBarUpdate or other event is running that the object will at least not be destroyed until the method exits... if that's not addressed by this and it isn't already written up I can write it up in a separate post.

[NinjaTrader_Matthew]

Thank you Matthew. Does the new internal build also resolve the issue whereby the state can be changed to terminated while OnBarUpdate or other events are still running? In the current multithreading model at least in beta 9 it is possible for an indicator to be destroyed by one thread while OnBarUpdate is still running in another, causing some of its resources to become unavailable and resulting in unexpected exceptions. It does seem like a reasonable expectation that while the OnBarUpdate or other event is running that the object will at least not be destroyed until the method exits... if that's not addressed by this and it isn't already written up I can write it up in a separate post.

I am not 100% sure I follow so if you can please write up a test case, I'll make sure it is tested. Thanks.

[QuantKey_Bruce]

I am not 100% sure I follow so if you can please write up a test case, I'll make sure it is tested. Thanks.

I have documented it at http://ninjatrader.com/support/forum...254#post451254. Thank you.

[NinjaTrader_Matthew]

I have documented it at http://ninjatrader.com/support/forum...254#post451254. Thank you.

I appreciate it - we'll look at it with the changes we mentioned and update that thread if needed.