Unhandled exception: the read lock is being released without being held

[Silent]

I Wrote an indicator and when I add it to a chart I get the error: Unhandled exception: the read lock is being released without being held. Ninjatrader also becomes very slow.

As I'm a beginner with regards to Ninjatrader and programming so I can't fully exclude it's a user error but I think users are not supposed to get unhandled exceptions.

Stripped pretty much everything out of the indicator but error remains as long as I maintain the while loop.

the code:

protected override void OnStateChange()
{
if (State == State.SetDefaults)
{
Description = @"Bull Divergence";
Name = "MyBullDivErr2";
Calculate = Calculate.OnBarClose;
IsOverlay = false;
DisplayInDataBox = true;
DrawOnPricePanel = true;
DrawHorizontalGridLines = true;
DrawVerticalGridLines = true;
PaintPriceMarkers = true;
ScaleJustification = NinjaTrader.Gui.Chart.ScaleJustification.Right;
//Disable this property if your indicator requires custom values that cumulate with each new market data event.
//See Help Guide for additional information.
IsSuspendedWhileInactive = true;
MinPeriod = 5;
MaxPeriod = 30;
AddPlot(Brushes.Orange, "BullDiv");
}
else if (State == State.Configure)
{
}
}

protected override void OnBarUpdate()
{
int i = MinPeriod;
BullDiv[0] = 0;
while (i < MaxPeriod && BullDiv[0] <= 0);
{
if (Low[0] > Low[i] )
{
BullDiv[0] = i;
}
i++;
}

}

[NinjaTrader_JessicaP]

Hello Silent, and thank you for your question.

I was unable to reproduce what you saw on my system using the code you provided. I am including a complete c# file. So I may better assist you, I would like to ask two questions,

• Can you correct the code I added outside OnBarUpdate and OnStateChange so it matches yours?
• Can you also review the changes I made to OnBarUpdate to enable us to better debug your code, to ensure it is equivalent to the code you sent our way?

You may attach files using the paperclip icon in the "go advanced" window.

[Silent]

I just pasted your code in the script editor and compiled it. The code still doesn't plot but the error does not occur. The original code is changed but below is an almost identical sample that does generate the error complete with the auto generated code.

Your rewritten code looks correct but as I'm a beginner it's easy to overlook something...

The complete code is:
#region Using declarations
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.ComponentModel.DataAnnotations;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows;
using System.Windows.Input;
using System.Windows.Media;
using System.Xml.Serialization;
using NinjaTrader.Cbi;
using NinjaTrader.Gui;
using NinjaTrader.Gui.Chart;
using NinjaTrader.Gui.SuperDom;
using NinjaTrader.Gui.Tools;
using NinjaTrader.Data;
using NinjaTrader.NinjaScript;
using NinjaTrader.Core.FloatingPoint;
using NinjaTrader.NinjaScript.DrawingTools;
#endregion

//This namespace holds Indicators in this folder and is required. Do not change it.
namespace NinjaTrader.NinjaScript.Indicators
{
public class MyBullDivErr : Indicator
{
protected override void OnStateChange()
{
if (State == State.SetDefaults)
{
Description = @"Bull Divergence";
Name = "MyBullDivErr";
Calculate = Calculate.OnBarClose;
IsOverlay = false;
DisplayInDataBox = true;
DrawOnPricePanel = true;
DrawHorizontalGridLines = true;
DrawVerticalGridLines = true;
PaintPriceMarkers = true;
ScaleJustification = NinjaTrader.Gui.Chart.ScaleJustification.Right;
//Disable this property if your indicator requires custom values that cumulate with each new market data event.
//See Help Guide for additional information.
IsSuspendedWhileInactive = true;
MinPeriod = 5;
MaxPeriod = 30;
AddPlot(Brushes.Orange, "BullDiv");
}
else if (State == State.Configure)
{
}
}

protected override void OnBarUpdate()
{
if (CurrentBar < MaxPeriod)
return;

int i = MinPeriod;
BullDiv[0] = 0;
while (i < MaxPeriod && BullDiv[0] <= 0);
{
if (Low[0] > Low[i])
{
BullDiv[0] = i;
}
i++;
}

}

#region Properties
[Range(1, int.MaxValue)]
[NinjaScriptProperty]
[Display(Name="MinPeriod", Order=1, GroupName="Parameters")]
public int MinPeriod
{ get; set; }

[Range(1, int.MaxValue)]
[NinjaScriptProperty]
[Display(Name="MaxPeriod", Order=2, GroupName="Parameters")]
public int MaxPeriod
{ get; set; }

[Browsable(false)]
[XmlIgnore]
public Series<double> BullDiv
{
get { return Values[0]; }
}
#endregion

}
}

#region NinjaScript generated code. Neither change nor remove.

namespace NinjaTrader.NinjaScript.Indicators
{
public partial class Indicator : NinjaTrader.Gui.NinjaScript.IndicatorRenderBase
{
private MyBullDivErr[] cacheMyBullDivErr;
public MyBullDivErr MyBullDivErr(int minPeriod, int maxPeriod)
{
return MyBullDivErr(Input, minPeriod, maxPeriod);
}

public MyBullDivErr MyBullDivErr(ISeries<double> input, int minPeriod, int maxPeriod)
{
if (cacheMyBullDivErr != null)
for (int idx = 0; idx < cacheMyBullDivErr.Length; idx++)
if (cacheMyBullDivErr[idx] != null && cacheMyBullDivErr[idx].MinPeriod == minPeriod && cacheMyBullDivErr[idx].MaxPeriod == maxPeriod && cacheMyBullDivErr[idx].EqualsInput(input))
return cacheMyBullDivErr[idx];
return CacheIndicator<MyBullDivErr>(new MyBullDivErr(){ MinPeriod = minPeriod, MaxPeriod = maxPeriod }, input, ref cacheMyBullDivErr);
}
}
}

namespace NinjaTrader.NinjaScript.MarketAnalyzerColumns
{
public partial class MarketAnalyzerColumn : MarketAnalyzerColumnBase
{
public Indicators.MyBullDivErr MyBullDivErr(int minPeriod, int maxPeriod)
{
return indicator.MyBullDivErr(Input, minPeriod, maxPeriod);
}

public Indicators.MyBullDivErr MyBullDivErr(ISeries<double> input , int minPeriod, int maxPeriod)
{
return indicator.MyBullDivErr(input, minPeriod, maxPeriod);
}
}
}

namespace NinjaTrader.NinjaScript.Strategies
{
public partial class Strategy : NinjaTrader.Gui.NinjaScript.StrategyRenderBase
{
public Indicators.MyBullDivErr MyBullDivErr(int minPeriod, int maxPeriod)
{
return indicator.MyBullDivErr(Input, minPeriod, maxPeriod);
}

public Indicators.MyBullDivErr MyBullDivErr(ISeries<double> input , int minPeriod, int maxPeriod)
{
return indicator.MyBullDivErr(input, minPeriod, maxPeriod);
}
}
}

#endregion

[NinjaTrader_JessicaP]

Hello Silence,

While we can not help much with the correct operation of your code, as that behavior is defined by you and constitutes development, we can help get you to a clean compile state, and we can help ensure Ninja is working properly, and we can help you learn the platform.

I was hoping that you could provide me with a copy of the code that was not compiling correctly? The reasons why it is not compiling correctly may help me find you an answer.

I am attaching a .cs file to this e-mail which is simply a formatted copy of your code that we may work with.

If you could let me know what your goal is, in terms of what you would like to plot, in plain language, I may be able to answer further questions about the operation of your code.

[Silent]

I don't think there is a real issue with the programming. That is it's probably bad programming and inefficient as I'm completely new to c# and have only very little other programming experience. For now I'm just playing around a little to get a feel what is possible and how things work in Niinjatrader. The reason I posted here is because of the error generated. I don't think users should get unhandled exception errors. So the issue is not about the programming itself.

The code I pasted is code that generates the error. I figured out how to export the indicator so see also the attached file.

[NinjaTrader_JessicaP]

Hello Silent,

Can you clarify what you mean when you say "I don't think users should be able to get unhandled exception errors" ?

I was able to determine that, in the code you sent me, this

[FONT=Courier New]while (i < MaxPeriod && BullDiv[0] <= 0)[SIZE=4][B][SIZE=5];[/SIZE][/B][/SIZE]
{
    if (Low[0] > Low[i])
    {
        BullDiv[0] = i;
    }
    i++;
}[/FONT]

is equivalent to this

[FONT=Courier New]while (true);[/FONT][SIZE=4][SIZE=2]
[/SIZE][/SIZE]

or in other words, "reach this point in the code and wait forever". Removing the bolded semicolon will allow your code to compile and work properly.

Please let us know if there is any other way we can help.

[Silent]

I don't know what you mean with wait forever, but if you mean to say it's an endless loop, I don't think so. Every loop i will be incresed and at one point, maximum (maxperiod-minperiod) cycles i will exceed maxperiod and the condition is no longer met.

With the statement : "I don't think users should be able to get unhandled exception errors" I mean exactly what I say. I think user should not get unhandled exception errors. Errors should be caught and handled by the program either corrective so the user doesn't notice or by giving an error that's meaningfull for the enduser. Which may be in the form of a hint about what corrective action is needed or otherwise a pointer to contact support with certain info (if the problem persists). At least that's what I've been told in my application management course.

[koganam]

I don't know what you mean with wait forever, but if you mean to say it's an endless loop, I don't think so. Every loop i will be incresed and at one point, maximum (maxperiod-minperiod) cycles i will exceed maxperiod and the condition is no longer met.

With the statement : "I don't think users should be able to get unhandled exception errors" I mean exactly what I say. I think user should not get unhandled exception errors. Errors should be caught and handled by the program either corrective so the user doesn't notice or by giving an error that's meaningfull for the enduser. Which may be in the form of a hint about what corrective action is needed or otherwise a pointer to contact support with certain info (if the problem persists). At least that's what I've been told in my application management course.

No it will not, because you have coded an endless loop that never enters that code block. Remove the semi-colon as directed, so that the code block will get entered.

This is an endless loop:

while (i < MaxPeriod && BullDiv[0] <= 0);

Specifically it says that: "While the bracketed statement is true, do nothing". Of course, then, as the code does nothing, the statement remains true forever. That is the definition of an endless while loop: a loop that has no exit condition.

[Silent]

Ok, clear, Thanks!

[NinjaTrader_JessicaP]

Hello Silent,

I am glad we were able to get you to a clean compile and runtime state.

With the statement : "I don't think users should be able to get unhandled exception errors" I mean exactly what I say. I think user should not get unhandled exception errors. Errors should be caught and handled by the program either corrective so the user doesn't notice or by giving an error that's meaningfull for the enduser. Which may be in the form of a hint about what corrective action is needed or otherwise a pointer to contact support with certain info (if the problem persists). At least that's what I've been told in my application management course.

I believe you are being taught correctly in your class. However, there are a few conditions which would make me hesitant to say that this should never happen.

First, this particular case was an example of something called a "halting problem". I would like to provide a publicly available wikipedia link for more information, https://en.wikipedia.org/wiki/Halting_problem , but generally it is impossible to code a program in such a way that it knows whether or not it will continue or run forever. This particular case was trivial enough that a very clever compiler - but a generally either incomplete or slow one even if it would compile this quickly and correctly, see this to see why https://en.wikipedia.org/wiki/Boolea...bility_problem - could detect that you had an infinite loop, and could warn you about it. In practice most developers would complain about compilers detecting this sort of thing even if the compiler could be made practical though, since the ability to intentionally create infinite loops is vital especially with multi-threaded and network programming.

So in plain language, it's impossible for any computer program to prevent this kind of runtime error, and even if it was possible, trying to do so would usually be a bad idea.

What you were taught was still correct, however. Your teacher was simply talking about a different kind of problem. Whenever software is known to fail a certain way, often intentionally to prevent worse things from happening, programmers like to create known exceptions. Whenever there is a known exception provided by the compiler or a library you are using, those exceptions should be explicitly handled.

However, due to some physical limitations in computer science, your teachers advice should generally be applied to compile time problems, not runtime problems.

There is one other consideration. NinjaScript is a layer on top of another tool, the MSDN C# language. We have very smart people testing our tools and trying to break them, and coming up with known limitations of our platform. We are currently beta testing NinjaTrader 8 this way. We have, therefore, a lot of explicit exceptions that can be thrown. However, if we tried to come up with an exception for every possible circumstance, we would never "fall through" to MSDN, or in other words, let Microsoft decide what to do instead of deciding what to do ourselves. Sometimes it is important to let MSDN handle exceptions instead of us, especially with new exceptions or exceptions in software Microsoft controls, so that enough information gets to you, the end user, to be able to find a solution. Every time we attempt to interpret something and make it user friendly, we risk destroying context and information, because Microsoft can't possibly be aware of exactly how we are formatting things, and may make changes to their code freely, that we would then be unaware of. The trade-off is that sometimes, if we do fall through, the MSDN software will not provide an explicit message.

This should, therefore, always be a careful nuanced decision.

Please let me know if I can clarify anything in this ticket, or if there is any other way I can be of assistance.

[koganam]

... With the statement : "I don't think users should be able to get unhandled exception errors" I mean exactly what I say. I think user should not get unhandled exception errors. Errors should be caught and handled by the program either corrective so the user doesn't notice or by giving an error that's meaningfull for the enduser. Which may be in the form of a hint about what corrective action is needed or otherwise a pointer to contact support with certain info (if the problem persists). At least that's what I've been told in my application management course.

You are responsible for your own code. You should not really expect someone/something else to catch your logic errors for you. An inadvertent endless loop is your error, and needs to be handled by you after you see the effect.

An "unhandled exception" is telling you precisely that: you have created an issue and have not made arrangements to handle an exception if one should occur. So the controlling framework/program has thrown the exception all the way up the stack and not been able to handle it either, and is now informing you. It is now up to you to do something about your lack of exception handling, or prevent the possibility of generating the exception. In other words, you have been informed. Maybe not in the manner that you would like, but still informed nonetheless.