LabVIEW: Calling Execution.Break in a Trace UI message event callback after a Step Over causes the next Step Over to be a no-op?

[chriscarner]

I encountered something strange today. While paused in an active execution with the execution pointer at the last step in Main, I call Step Over, and in the resulting Trace UI message event callback, I call Execution.Break (the code doesn't realize that the execution will stop anyway); after the callback, the execution pauses at the end of the Main step group. Then, when I call Step Over again, I get the UIMsg_ResumeFromBreak and UIMsg_BreakOnBreakpoint, but no UIMsg_Trace as expected, and the execution doesn't seem to change state. I would expect the execution pointer to advance to the start of the next step after the calling step (there are no Cleanup steps).

Note that this does not occur when the execution pointer does not point to the last step in Main, and also does not occur when the execution does not pause before running the last step in Main.

My only thought is that the TestStand engine is perhaps erroneously inserting an extra breakpoint somewhere, but I don't see a way to determine if the execution will break at the end of a step (including after the last step in a step group) without manually calculating it sometime earlier. Or maybe I'm ignorant of something else going on? Any help is appreciated.

[hnesmith]

if you call execution.break then step over in the other steps, do you see UIMsg_Trace? 

have you tried calling step over twice to see if it progresses as it would if there were an additional breakpoint? 

[chriscarner]

Actually, I went back to verify, and I was mistaken, the issue occurs no matter what step in Main you start on. So, to answer your first question, no, I don't see the UIMsg_Trace.

To answer your second question, yes, calling step over twice progresses the execution as it would if there were an additional breakpoint.

[dug9000]

What exactly are you trying to accomplish by calling Break inside of a trace handler?

-Doug