Setting a Breakpoint

A breakpoint is a set location in source code that indicates to the Source Debugger that any thread executing that source code is to be paused immediately prior to executing it (see also Data Breakpoints).

Placing a breakpoint freezes the state of the application being debugged at a specific point so that you may examine it.

Setting a Breakpoint

To set a breakpoint:

Select the line of code at which you wish to place the breakpoint (line selection is keyboard and mouse driven). A breakpoint indicator will appear at the selected line and the breakpoint window will reflect the information.

What Happens Once a Breakpoint Has Been Set?

Application execution will continue normally at full speed until a statement that contains a breakpoint is about to be executed. At that point, execution of the thread that is attempting to execute the statement containing the breakpoint will be suspended and another entry will be made in the breakpoint tab of the Source Debugger: action window, listing the thread that has been suspended and the breakpoint that has been hit. The breakpoint tab will be forced to the front of the action window, the tab containing the source code with the breakpoint will be forced to the front of the code display window, and the Source Debugger window itself will be made the active window. Additionally, the module trees will automatically be refreshed and positioned at the module instance that contains the breakpoint. This means that you can see a "snapshot" state of the module trees at the time that the breakpoint was encountered.

The breakpoint indicator will change to show that it has been "hit" by displaying a yellow arrow over its top:

What Happens to Other Threads Once a Breakpoint Has Been Set?

Note that only the thread that executes a statement containing a breakpoint will be suspended. Other threads within VTS, including those within your application, will continue to run normally. If this were not the case, you wouldn't be able to use the Source Debugger, as it is merely a script application. The implication of this is that while one thread is paused on a breakpoint, another thread may attempt to execute the same statement, and hence cause another breakpoint. This would result in exactly the same sequence of events, with a second entry showing a hit breakpoint being made in the breakpoints tab of the action window.

While a thread is paused at a breakpoint, you may navigate to any module in any of the module trees that you wish, and examine or modify the contents of any data variable. In other words, suspension of execution of a thread affords you the time to have a "look-around" at the state of things at a given point in the execution of your application. This can be most useful in detecting transitional states that would otherwise be difficult to find.

How Do I Continue Execution Past a Breakpoint?

To continue execution past a breakpoint, ensure that the breakpoint from which you wish to continue execution is selected in the breakpoints tab of the action window, and then click the Continue button. The selected "hit" breakpoint entry in the breakpoints tab of the Action Window will be removed (the breakpoint will remain, but the breakpoint event will be removed). If there are multiple breakpoints "hit", only the breakpoint event selected in the breakpoints tab will be continued.

What Happens If a Critical Section is Hit?

A breakpoint can be placed on any source code line whose module has been compiled with debugger symbols (see the "Note" in Run the Source Debugger). This includes scripts that contain critical sections (see CriticalSection). When a breakpoint within a CriticalSection is "hit", the CriticalSection is effectively released and re-acquired when you continue execution from that point. This allows other VTS threads to run, including the Source Debugger. Depending on the code contained within the CriticalSection, this may cause behavioral differences within your application.