Breakpoints

4 Key excerpts on "Breakpoints"

• 

  eBook - ePub

  Professional Visual Studio 2010

  • Nick Randolph, David Gardner, Chris Anderson, Michael Minutillo(Authors)
  • 2010(Publication Date)
  • Wrox

    (Publisher)

  The call stack is generated using function addresses. As such, the breakpoint that is set is an address breakpoint. This type of breakpoint is only useful within a single debugging session, because function addresses are likely to change when an application is modified and rebuilt.

  Adding Break Conditions

  Though Breakpoints are useful for pausing an application at a given point to review variables and watch application flow, if you are looking for a particular scenario it may be necessary to break only when certain conditions are valid. Breakpoints can be tailored to search for particular conditions, to break after a number of iterations, or even be filtered based on process or machine name.

  Condition

  A breakpoint condition can be specified by selecting Condition from the Breakpoint item on the right-click context menu for the breakpoint. This brings up the Breakpoint Condition dialog shown in Figure 40-6 , which accepts a Boolean expression that determines whether the breakpoint will be hit. If the expression evaluates to false , the application continues past the breakpoint without breaking.

  FIGURE 40-6

  In the case of Figure 40-6 , which is for a breakpoint set within the Order class, the condition specifies that the order total must be greater than 1000. As with most debugging windows, the Condition field provides rich IntelliSense support to aid writing valid conditions. If an invalid condition is specified, the debugger throws an appropriate error message and the application will break the first time the breakpoint is reached.

  When a condition, or a hit count, as shown in the next section, is placed on a breakpoint, the breakpoint changes appearance. The solid red dot is replaced with a red dot with a white cross. When you move your mouse across this dot, the tooltip provides useful information about the breakpoint condition, as illustrated in Figure 40-7 .

  FIGURE 40-7

  Sometimes it is more relevant to know when this condition changes status, rather than when it is true. The Has Changed option breaks the application when the status of the condition changes. If this option is selected, the application will not break the first time the breakpoint is hit, because there is no previous status to compare against.

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Professional Visual Studio 2015

  • Bruce Johnson(Author)
  • 2015(Publication Date)
  • Wrox

    (Publisher)

  The first stage in debugging an application is usually to identify the area causing the error by setting a breakpoint and gradually stepping through the code. The next chapter covers in detail setting Breakpoints and working with the current execution point. Breakpoints are marked in the code window with a red dot in the margin of the page and a colored highlighting of the code itself.

  When a breakpoint is encountered, the current execution point is marked with a yellow arrow in the margin, and the actual code is also highlighted in yellow. This marker can be dragged forward and backward to control the order of execution. However, you should do this judiciously because it modifies the behavior of the application.

  DataTips

  After hitting a breakpoint, the application is paused, or is in Debug Mode. In this mode, you can retrieve information about current variables simply by hovering your mouse over the variable name. Figure 40.1 shows that the value of the mCustomerName variable is currently “Peter Gibbons.” This debugging tooltip is commonly referred to as a DataTip, and you can use it not only to view the values of simple types, such as strings and integers, but also to drill down and inspect more complex object types, such as those made up of multiple nested classes.

  Note

  DataTips are used to both query and edit the value of a variable.

  In Chapter 42 , “DataTips, Debug Proxies, and Visualizers,” you'll learn how the layout of this DataTip can be customized using type proxies and type visualizers.

  The Breakpoints Window

  When debugging a complex issue, you can set numerous Breakpoints to isolate the problem. Unfortunately, this has two side effects. One, the execution of the application is hampered because you have to continually press F5 to resume execution. Two, and more significantly, the execution of the application is slowed considerably by the presence of conditional Breakpoints, which enable you to specify an expression that is executed to determine if the application should be paused. The more complex the breakpoint conditions are, the slower the application will run. Because these Breakpoints can be scattered through multiple source files, it becomes difficult to locate and remove Breakpoints that are no longer required.

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Professional Visual Studio 2017

  • Bruce Johnson(Author)
  • 2017(Publication Date)
  • Wrox

    (Publisher)

  Long gone are the days when debugging an application involved adding superfluous output statements to track down where an application was failing. Visual Studio 2017 provides a rich, interactive debugging experience that includes Breakpoints, tracepoints, and the Edit and Continue feature. This chapter covers how you can use these features to debug your application.

  Breakpoints

  A breakpoint is used to pause, or break, an application at a particular point of execution. An application that has been paused is in Break mode, causing a number of the Visual Studio 2017 windows to become active. For example, you can use the Watch window to view variable values. Figure 31-1 shows a breakpoint added to the constructor of the Customer class. The application breaks on this line if the Customer class constructor is called.

  FIGURE 31-1

  Setting a Breakpoint

  You can set Breakpoints either through the Debug menu, using the Toggle Breakpoint item from the right-click context menu, or by using the keyboard shortcut F9. The Visual Studio 2017 code editor also provides a shortcut for setting a breakpoint using a single mouse-click in the margin. An application can be paused only on a line of executing code. This means that a breakpoint set on either a comment or a variable declaration is repositioned to the next line of executable code when the application is run.

  Simple Breakpoints

  You can set a breakpoint on a line of code by placing the cursor on that line and enabling a breakpoint using any of the following methods:

  • Selecting Toggle Breakpoint from the Debug menu
  • Pressing F9
  • Clicking once in the margin of the code window with the mouse

  Once a breakpoint has been set for a line, additional details for the breakpoint can be specified through Settings. You can access Settings by right-clicking the content menu or hovering your mouse over the breakpoint icon in the margin and clicking on the gear image (see Figure 31-1 ). Both actions cause the Settings subwindow to appear (see Figure 31-2 ). In this window, you can see that the breakpoint is set at line 13 of the Customer.cs file. There is also a character number that indicates the character position in the line where the breakpoint is set. This is only really useful when multiple statements appear on a single line. Clicking on the link where that information appears changes the interface to allow for modification of the line and character position, as shown in Figure 31-3

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  The Art of Designing Embedded Systems

  • Jack Ganssle(Author)
  • 1999(Publication Date)
  • Newnes

    (Publisher)

  A lot of applications now just can't survive the problems inherent in using Breakpoints. After all, stopping the code stops everything; your en- tire system shuts down. If your code controls a moving robot arm, for ex- ample, and you stop the code as the arm starts moving, it will keeping going and going and going.., until something breaks or a limit switch is actuated. Years ago I worked on a 14-ton steel gauge; a Z80 controlled the motion of this monster on railroad tracks. Hit a breakpoint and the system ran off the end of the tracks! Datacomm is another problem area. Stop the code via a breakpoint, with data packets still streaming in, and there's a good chance the receiv- ing device will time out and start transmitting retry requests. Though Breakpoints are truly wonderful debugging aids, they are like Heisenberg's uncertainty principle: the act of looking at the system changes it. You can cheat Heisenberg~at least in debugging embedded code!~by using real-time trace, a feature available on all emulators and some smart logic analyzers. Trace collects the execution stream of the code in real time, without slowing or altering the flow. It's a completely nonintrusive way of view- ing what happens. Trace changes the philosophy of debugging. No longer does one stop the code, examine various registers and variables, and then timidly step along. With trace your program is running at full tilt, a breakneck pace that trace does nothing to alter. You capture program flow, and then examine what happened, essentially looking into the past as the code continues on (Figure 4-6). Trace shows only what happens on the bus. You can view neither reg- isters nor variables unless an instruction reads or writes them to memory. Worse, C's stack-based design often makes it impossible to view variables that were captured. You may see the transactions (pushes and pops), but the tool may display neither the variable name nor the data in its native type.

  Sign up to read

  Learn more about book