Step Into Debugging

3 Key excerpts on "Step Into Debugging"

• 

  eBook - ePub

  Ivor Horton's Beginning Visual C++ 2008

  • Ivor Horton(Author)
  • 2011(Publication Date)
  • Wrox

    (Publisher)

  11Debugging Techniques

  If you have been doing the exercises in the previous chapters, you have most likely been battling with bugs in your code. In this chapter you will explore how the basic debugging capabilities built into Visual C++ 2008 can help with this. You will also investigate some additional tools that you can use to find and eliminate errors from your programs, and see some of the ways in which you can equip your programs with specific code to check for errors.

  In this chapter, you will learn about:

  • How to run your program under the control of the Visual C++ 2008 debugger
  • How to step through your program a statement at a time
  • How to monitor or change the values of variables in your programs
  • How to monitor the value of an expression in your program
  • The call stack
  • Assertions and how to use them to check your code
  • How to add debugging specific code to a program
  • How to detect memory leaks in a native C++ program
  • How to use the execution tracing facilities and generate debugging output in C++/CLI programs

  Understanding Debugging

  Bugs are errors in your program and debugging is the process of finding and eliminating them. You are undoubtedly aware by now that debugging is an integral part of the programming process—it goes with the territory as they say. The facts about bugs in your programs are rather depressing:

  • Every program you write that is more than trivial will contain bugs that you need to try to expose, find, and eliminate if your program is to be reliable and effective. Note the three phases here—a program bug is not necessarily apparent; even when it is apparent you may not know where it is in your source code; and even when you know roughly where it is, it may not be easy to determine what exactly is causing the problem and thus eliminate it.
  • Many programs that you write will contain bugs even after you think you have fully tested them.
  • Program bugs can remain hidden in a program that is apparently operating correctly—sometimes for years. They generally become apparent at the most inconvenient moment.

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  PROC SQL

  Beyond the Basics Using SAS, Third Edition

  • Kirk Paul Lafler(Author)
  • 2019(Publication Date)
  • SAS Institute

    (Publisher)

  The Science of Debugging by Matthew A. Telles and Yuan Hsieh (The Coriolis Group, 2001).

  The debugging process consists of five steps. See Table 11.1 .

  Table 11.1: Debugging Process Steps and Tasks

  Debugging Step	Task Description
  Problem Identification	1.        Determine if a bug exists in the code. 2.        Determine what the problem is by playing detective. 3.        Describe why the problem is a bug. 4.        Determine what the code should do. 5.        Determine what the code is doing.
  Information Collection	1.        Collect user comments and feedback. 2.        Collect personal observations and symptoms. 3.        Review SAS log information. 4.        Collect test case(s) that highlight the problem. 5.        Capture environmental information (for example, system settings, operating environment, external elements, etc.).
  Problem Assessment & Classification	1.        Develop a theory about what caused the problem. 2.        Review the code. 3.        Classify the problem into one of the following categories: ◦           Requirements problem ◦           Syntax error ◦           CPU problem ◦           Memory problem ◦           Storage problem ◦

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Troubleshooting Java

  Read, debug, and optimize JVM applications

  • Laurentiu Spilca(Author)
  • 2023(Publication Date)
  • Manning

    (Publisher)

  Unlike a text paragraph, reading code is not linear. Each instruction might create a new plan you need to investigate. The more complex the logic you explore, the more plans you need to open. The more plans you open, the more complex the process becomes. One trick to speeding up a code investigation process is to open as few plans as possible.
• A debugger is a tool that allows you to pause the app’s execution on a specific line so that you can observe the app’s execution, step by step, and the way it manages data. Using a debugger can help you to reduce some of the cognitive load of reading code.
• You can use breakpoints to mark the specific lines of code where you want the debugger to pause an app's execution so you can evaluate the values of all the variables in the scope.
• You can step over a line, which means continuing to the next execution line in the same plan, or step into a line, which means going into detail on the instruction on which the debugger paused the execution. You should minimize the number of times you step into a line and rely more on stepping over. Every time you step into a line, the investigation path gets longer and the process more time consuming.
• Even though using the mouse and the IDE’s GUI to navigate through the code is initially more comfortable, learning to use the keyboard shortcuts for these operations will help you debug faster. I recommend you learn the keyboard shortcuts of your favorite IDE and use them instead of triggering the navigation with the mouse.
• After stepping into a line, first read the code and try to understand it. If you can figure out what happens, use the step out operation to return to the previous investigation plan. If you don’t understand what happens, identify the first unclear instruction, add a breakpoint, and start debugging from there.