NT making a bogus call on my indicator

[ETFVoyageur]

I have come across cases when developing where that has not really gotten rid of the errors that I may have made. You may want to remove the compiled gumball completely and let NT generate a new one when it starts. That is the only sure way that I have found sometimes to get NT back to functioning, especially when I have made a mistake that royally hoses the system, and all my repair efforts are in vain.

I have also done that. I had to remove NinjaTrader.Custom.dll several times to even come up. I've probably removed it at least a half-dozen times this afternoon. That does not fix the problem.

--EV

[ETFVoyageur]

Clone is an interesting issue. I have noticed it in my traces before, but always cloning before the instance being cloned is terminated. I do not know what is different today such that NT is using an already-destroyed instance to clone from.

--EV

[ETFVoyageur]

My thanks to Mr. K for suggesting cleaning everything out. Unfortunately, that did not solve the problem. Here's what I did; if anyone has any more ideas, please let me know.

1. Comment out the body of my Clone() override and put just a simple Print() statement in it -- that way I would be accessing as little as possible, just in case it gets called after the instance is destroyed. Then compile with this change
2. Exit NT and remove the files NinjaTrader.Custom.xml and NinjaTrader.Custom.dll
3. Restart NT. It came up without my indicator on the chart. My indicator was also not available on the Indicators dialog list, so I took that as evidence that I had done a thorough clean-out.
4. Recompile, exit NT, and restart NT. Now my indicator was there had a panel, but no plots were drawn. The trace output had the old familiar error shown in a previous posting. Note that the error is NT's message, not mine. Also note that it is after the object was terminated -- not surprising it has an error if it had to deal with an already-destroyed object.

08/05/15  #1  Entry: VsaModelIndicator.DoStateChange()  (OnStateChange(Realtime) started, State.Realtime)  CurrentBar=248   C (Daily)
08/05/15  #1  Exit:   VsaModelIndicator.DoStateChange()  (OnStateChange(Realtime) completed, State.Realtime)  CurrentBar=248   C (Daily)
08/11/14  #1  Entry: VsaModelIndicator.DoStateChange()  (OnStateChange(Terminated) started, State.Terminated)  CurrentBar=248   C (Daily)
08/11/14  [B]#1  Exit: [/B]  VsaModelIndicator.DoStateChange()  (OnStateChange([B]Terminated[/B]) completed,[B] State.Terminated[/B])  CurrentBar=248   C (Daily)
[B]Indicator 'VsaModelIndicator': Error on calling 'OnRender' method on bar -1: Index was outside the bounds of the array.[/B]

I then hit "F5" to refresh the chart. The trace output shows that Clone() got called in the state State.Finalized, which is wrong. Here is the full annotated trace.

//The first part is all normal
03:00:59  #1  Entry: VsaModelIndicator.VsaModelIndicator()  (Constructor started , State.SetDefaults)  CurrentBar=n/a   <no instrument>
03:00:59  #1  Exit:   VsaModelIndicator.VsaModelIndicator()  (Constructor completed, State.SetDefaults)  CurrentBar=n/a   <no instrument>
03:00:59  #1  Entry: VsaModelIndicator.DoStateChange()  (OnStateChange(SetDefaults) started, State.SetDefaults)  CurrentBar=n/a   <no instrument>
03:00:59  #1  Exit:   VsaModelIndicator.DoStateChange()  (OnStateChange(SetDefaults) completed, State.SetDefaults)  CurrentBar=n/a   <no instrument>
03:01:00  #1  Entry: VsaModelIndicator.DoStateChange()  (OnStateChange(Configure) started, State.Configure)  CurrentBar=n/a   C (Daily)
03:01:00  #1  Exit:   VsaModelIndicator.DoStateChange()  (OnStateChange(Configure) completed, State.Configure)  CurrentBar=n/a   C (Daily)
03:01:00  #1  Entry: VsaModelIndicator.DoStateChange()  (OnStateChange(DataLoaded) started, State.DataLoaded)  CurrentBar=n/a   C (Daily)
03:01:00  #1  Exit:   VsaModelIndicator.DoStateChange()  (OnStateChange(DataLoaded) completed, State.DataLoaded)  CurrentBar=n/a   C (Daily)
03:01:00  #1  Entry: VsaModelIndicator.DoStateChange()  (OnStateChange(Historical) started, State.Historical)  CurrentBar=n/a   C (Daily)
03:01:00  #1  Exit:   VsaModelIndicator.DoStateChange()  (OnStateChange(Historical) completed, State.Historical)  CurrentBar=n/a   C (Daily)
08/11/14  #1  Entry: VsaModelIndicator.OnBarUpdate()  (OnBarUpdate() started, State.Historical)  CurrentBar=0   C (Daily)
07/29/15  #1  Exit:   VsaModelIndicator.OnBarUpdate()  (OnBarUpdate() completed, State.Historical)  CurrentBar=243   C (Daily)
08/05/15  #1  Entry: VsaModelIndicator.DoStateChange()  (OnStateChange(Transition) started, State.Transition)  CurrentBar=248   C (Daily)
08/05/15  #1  Exit:   VsaModelIndicator.DoStateChange()  (OnStateChange(Transition) completed, State.Transition)  CurrentBar=248   C (Daily)
08/05/15  #1  Entry: VsaModelIndicator.DoStateChange()  (OnStateChange(Realtime) started, State.Realtime)  CurrentBar=248   C (Daily)
08/05/15  #1  Exit:   VsaModelIndicator.DoStateChange()  (OnStateChange(Realtime) completed, State.Realtime)  CurrentBar=248   C (Daily)

// Up until here, all is  normal.
[B]// What is not normal is getting terminated at this point.
// Instances do not normally get terminated until after they have been cloned[/B] to their successor (except for temp objects, which this one is not)
08/11/14  #1  Entry: VsaModelIndicator.DoStateChange()  (OnStateChange(Terminated) started, State.Terminated)  CurrentBar=248   C (Daily)
08/11/14 [B] #1[/B]  Exit:   VsaModelIndicator.DoStateChange()  (OnStateChange([B]Terminated[/B]) completed, [B]State.Terminated[/B])  CurrentBar=248   C (Daily)

// The next line is an NT internal error, probably because of continuing to operate with an already-destroyed instance.
//  Presumably getting a Render error is why there are no plot lines.
[B]Indicator 'VsaModelIndicator': Error on calling 'OnRender' method on bar -1: Index was outside the bounds of the array.[/B]

// That all happened bringing up the chart initially
// At this point my indicator has a panel on the chart, but the indicator plots were not drawn
// Now I did an "F5" to refresh the chart -- the rest of the trace is from that

// The next four lines -- the constructor and SetDefaults -- are normal
// Creating a new object, Object #2, at this time is normal.
// That is what happens when things are working correctly, too.
03:02:13  #2  Entry: VsaModelIndicator.VsaModelIndicator()  (Constructor started , State.SetDefaults)  CurrentBar=n/a   <no instrument>
03:02:13  #2  Exit:   VsaModelIndicator.VsaModelIndicator()  (Constructor completed, State.SetDefaults)  CurrentBar=n/a   <no instrument>
03:02:13  #2  Entry: VsaModelIndicator.DoStateChange()  (OnStateChange(SetDefaults) started, State.SetDefaults)  CurrentBar=n/a   <no instrument>
03:02:13  #2  Exit:   VsaModelIndicator.DoStateChange()  (OnStateChange(SetDefaults) completed, State.SetDefaults)  CurrentBar=n/a   <no instrument>

// The next line is the call to Clone(), to update the new object (#2) from the old object (#1)
//          * Doing that at this time is perfectly normal
[B]//          * What is NOT NORMAL is that the old object has already been destroyed
[/B]CLONE() CALLED TO CLONE FROM OBJECT #1 TO OBJECT #2   ([B]State = State.Finalized[/B])

// The rest of this trace is normal
03:02:13  #2  Entry: VsaModelIndicator.DoStateChange()  (OnStateChange(Configure) started, State.Configure)  CurrentBar=n/a   C (Daily)
03:02:13  #2  Exit:   VsaModelIndicator.DoStateChange()  (OnStateChange(Configure) completed, State.Configure)  CurrentBar=n/a   C (Daily)
03:02:13  #2  Entry: VsaModelIndicator.DoStateChange()  (OnStateChange(DataLoaded) started, State.DataLoaded)  CurrentBar=n/a   C (Daily)
03:02:13  #2  Exit:   VsaModelIndicator.DoStateChange()  (OnStateChange(DataLoaded) completed, State.DataLoaded)  CurrentBar=n/a   C (Daily)
03:02:13  #2  Entry: VsaModelIndicator.DoStateChange()  (OnStateChange(Historical) started, State.Historical)  CurrentBar=n/a   C (Daily)
03:02:13  #2  Exit:   VsaModelIndicator.DoStateChange()  (OnStateChange(Historical) completed, State.Historical)  CurrentBar=n/a   C (Daily)
08/11/14  #2  Entry: VsaModelIndicator.OnBarUpdate()  (OnBarUpdate() started, State.Historical)  CurrentBar=0   C (Daily)
07/29/15  #2  Exit:   VsaModelIndicator.OnBarUpdate()  (OnBarUpdate() completed, State.Historical)  CurrentBar=243   C (Daily)
08/05/15  #2  Entry: VsaModelIndicator.DoStateChange()  (OnStateChange(Transition) started, State.Transition)  CurrentBar=248   C (Daily)
08/05/15  #2  Exit:   VsaModelIndicator.DoStateChange()  (OnStateChange(Transition) completed, State.Transition)  CurrentBar=248   C (Daily)
08/05/15  #2  Entry: VsaModelIndicator.DoStateChange()  (OnStateChange(Realtime) started, State.Realtime)  CurrentBar=248   C (Daily)
08/05/15  #2  Exit:   VsaModelIndicator.DoStateChange()  (OnStateChange(Realtime) completed, State.Realtime)  CurrentBar=248   C (Daily)

I do not know how to make this any plainer. I have started from as vanilla a state as I know how to get to -- removing those two files and having to recompile to even make my indicator available. If anyone has anything else reasonable to try, please let me know. (Mr. K -- I trust you are satisfied I have tried what you suggested.)

This error does not happen when I have two plots and two valid getters for them. The problem happens very reproducibly when I have only one plot but still two getters. The first getter returns valid data (Values[0]). The second getter returns the most reasonable thing I could think of -- null -- since Values[1] would be accessing a non-existing array entry.

Barring new information, it seems plain to me that NT has a serious bug. The object is getting destroyed prematurely (perhaps as a result of some missing error checking on what the getter returns?) Then NT goes on to try to use the destroyed object. It is just plain wrong to be operating on a destroyed object. In this case the result is both internal errors (the rendering failure) and unexpected errors in the indicator code (the code I commented out would have thrown an exception when accessing NT objects, such as CurrentBar).

I don't know what else you want from me. I'll be glad to email my source files if you think that would help (that would be 4 files).

I trust I have pretty well proven that there is a bug. This bug really does need to get fixed. I am optimistic that the fix is some error-checking and handling, and not something very difficult. Please let me know what else I can do to help.

--EV

[ETFVoyageur]

My previous message was the maximum length, so this is really an addendum to that message. Here are the getters. In the NT error case, Signal is returning null.

If something else is needed, such as a specific error return, or an additional attribute on the getters, please let me know. I really need this fixed, because it is making me throw an exception in my override of Clone().

Note that in the normal, non-error, case the State is "Realtime" when Clone() is called. The problem appears to be NT lacking error checking, causing the instance to get destroyed, and then continuing to use the destroyed instance.

Matthew -- any further word on this one?

--EV

        /// Properties that provide convenient access to the plot(s)
        [Browsable(false)]      // Prevents the data series from being displayed in the indicator properties dialog, do not remove
        [XmlIgnore()]           // Ensures that the indicator can be saved/recovered as part of a chart template, do not remove
        // This property is the same as the standard NinjScript "Value", but works with the base class' indexing scheme -- may not be Values[0]
        public new Series<double> Value
        {
            get
            {
                return (rIndicatorPlot.index < 0)
                    ? null
                    : Values[rIndicatorPlot.index];
            }
        }

        [Browsable(false)]      // Prevents the data series from being displayed in the indicator properties dialog, do not remove
        [XmlIgnore()]           // Ensures that the indicator can be saved/recovered as part of a chart template, do not remove
        public Series<double> Signal
        {
            get
            {
                return (rSignalPlot.index < 0)
                    ? null
                    : Values[rSignalPlot.index];
            }
        }

[koganam]

My previous message was the maximum length, so this is really an addendum to that message. Here are the getters. In the NT error case, Signal is returning null.

If something else is needed, such as a specific error return, or an additional attribute on the getters, please let me know. I really need this fixed, because it is making me throw an exception in my override of Clone().

Note that in the normal, non-error, case the State is "Realtime" when Clone() is called. The problem appears to be NT lacking error checking, causing the instance to get destroyed, and then continuing to use the destroyed instance.

Matthew -- any further word on this one?

--EV

        /// Properties that provide convenient access to the plot(s)
        [Browsable(false)]      // Prevents the data series from being displayed in the indicator properties dialog, do not remove
        [XmlIgnore()]           // Ensures that the indicator can be saved/recovered as part of a chart template, do not remove
        // This property is the same as the standard NinjScript "Value", but works with the base class' indexing scheme -- may not be Values[0]
        public new Series<double> Value
        {
            get
            {
                return (rIndicatorPlot.index < 0)
                    ? null
                    : Values[rIndicatorPlot.index];
            }
        }

        [Browsable(false)]      // Prevents the data series from being displayed in the indicator properties dialog, do not remove
        [XmlIgnore()]           // Ensures that the indicator can be saved/recovered as part of a chart template, do not remove
        public Series<double> Signal
        {
            get
            {
                return (rSignalPlot.index < 0)
                    ? null
                    : Values[rSignalPlot.index];
            }
        }

Looks like you have a name clash, Value is identically Values[0] (a synonym, enforced internally), so should not be used as the name of a Plot() ?

[ETFVoyageur]

Looks like you have a name clash, Value is identically Values[0] (a synonym, enforced internally), so should not be used as the name of a Plot() ?

It is deliberate and should be fine as is. Note the modifier "new" in its declaration.

In my case I AddPlot() the value line first, so my construct is also returning Value[0]. Mine will also work if signal is added first and value second. I really do not like hard-coded numbers, indexes, etc.

As far as I know the order in Values[] and Plots[] should be the same. My way enforces that.

Also, when I am avoiding the NT bug (plotting both lines), everything plots just fine.

--EV

[koganam]

It is deliberate and should be fine as is. Note the modifier "new" in its declaration.

In my case I AddPlot() the value line first, so my construct is also returning Value[0]. Mine will also work if signal is added first and value second. I really do not like hard-coded numbers, indexes, etc.

As far as I know the order in Values[] and Plots[] should be the same. My way enforces that.

--EV

I did miss the new modifier. Jeez

You might still want to try using a completely different name, which if it works, means that there is still a bug in the implementation: there was a similar bug raised about using "new" in the Properties all the way back in Beta1, which was supposedly fixed.

ref: http://ninjatrader.com/support/forum...d.php?p=410893

[NinjaTrader_Matthew]

Will respond/comment once we have time out of our schedule to fully review and digest everything in this thread. If you have a clear, compilable, simplified version of your indicator with the exact steps needed to reproduce, should save us some time to analyze. Thanks.

[ETFVoyageur]

Will respond/comment once we have time out of our schedule to fully review and digest everything in this thread. If you have a clear, compilable, simplified version of your indicator with the exact steps needed to reproduce, should save us some time to analyze. Thanks.

Matthew,

Thanks for the reply.

There is no need to spend time on the entire thread. Early posting were when the problem was much less well-understood. All you really need to read is beginning with my two postings from last night. I believe that they cover the issue quite simply and completely.

--EV

[ETFVoyageur]

I did miss the new modifier. Jeez

You might still want to try using a completely different name, which if it works, means that there is still a bug in the implementation: there was a similar bug raised about using "new" in the Properties all the way back in Beta1, which was supposedly fixed.

ref: http://ninjatrader.com/support/forum...d.php?p=410893

That thread was using "new" in a different context. Nevertheless I did try renaming the variable just now and the behavior is unchanged.

--EV

[NinjaTrader_Matthew]

I must still be missing something as I cannot reproduce the error with this info. I'm not saying your bug is not reproducible, I'm saying I cannot reproduce with what I am interpreting you saying.

This error does not happen when I have two plots and two valid getters for them. The problem happens very reproducibly when I have only one plot but still two getters. The first getter returns valid data (Values[0]). The second getter returns the most reasonable thing I could think of -- null -- since Values[1] would be accessing a non-existing array entry.

Please provide a working sample.

[ETFVoyageur]

I must still be missing something as I cannot reproduce the error with this info. I'm not saying your bug is not reproducible, I'm saying I cannot reproduce with what I am interpreting you saying.

Please provide a working sample.

I'm already looking into that. I tried a trivial example and agree that does not show the bug. I guess I'll have to take a copy of my real code and start stripping it down. That may take a while.

What you need depends on how you go at the problem. If you are looking from the NT side to see how NT does an obviously very bad thing -- call methods on a destroyed object -- then my existing code would do fine. That is something you can do that I cannot do.

If you are coming from the indicator side, trying to understand what the indicator does to provoke the problem, then my existing code is too much for you to want to wade through.

--EV

[NinjaTrader_Matthew]

First I'd like to understand what your indicator is doing that is triggering the problem, and then I will work with development on what you're seeing and why that may had been a design decision, or a plain ol' bug.

[ETFVoyageur]

First I'd like to understand what your indicator is doing that is triggering the problem, and then I will work with development on what you're seeing and why that may had been a design decision, or a plain ol' bug.

I figured that is what you are trying to do.

As to "by design" -- it is NEVER an acceptable design to be calling methods on a destroyed object.

--EV

[ETFVoyageur]

This is chasing a will 'o the wisp. The problem was 100% reproducible, but I cannot reproduce it at the moment.

The bad news -- NT has a bug that is unlikely to get fixed. My tracing showed that, under some circumstance, NT will prematurely destroy an instance and then continue to call methods on that instance. That has got to be a bug. There is no way it is acceptable to call methods on an already-destroyed instance.

The good news -- it looks like I can get back to work. I'll let you know if I can again reproduce the bug.

--EV