Step Into Debugging

7 Key excerpts on "Step Into Debugging"

• 

  eBook - PDF

  C# Programming

  From Problem Analysis to Program Design

  • Barbara Doyle, , , (Authors)
  • 2015(Publication Date)
  • Cengage Learning EMEA

    (Publisher)

  Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s). Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it. 794 | Chapter 12: Debugging and Handling Exceptions STEPPING THROUGH CODE Instead of just setting specific breakpoints in your source code, you could step through your code line by line, see the execution path, and examine variable and expression values as they change. The Debug menu, which was shown in Figures 12-2 and 12-3, offers three commands for stepping through code while you are in break mode. These commands and their keyboard shortcuts are: Step Into (F11) Step Over (F10) Step Out (Shift+F11) Both the Step Into and Step Over commands tell the Debugger to execute the next line of code. The functionality of these two commands differs when a method is invoked. When the Step Into command encounters a line that contains a call to a method, the call is executed—then the program halts at the first line of code inside the called method. The Step Over command differs in that it executes the entire method called before it halts. It pauses at the first line of code outside the method. Step Into is useful for allowing you to look inside a method and examine the method’s program statements. Step Over completes all the program statements in the method before it halts—giving you no opportunity to examine the variables, expressions, or flow of program statements. Review Figure 12-2 and note that the Step Out option is not shown. It does not appear until you are in debugging mode. When debugging, as shown in Figure 12-3, you can see this added option. If you are executing statements inside a method and want to return to the calling method, this third command, Step Out , is useful.

  Sign up to read

  Learn more about book
• 

  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 - PDF

  Basic Data Structures and Program Statements

  • Xingni Zhou, Qiguang Miao, Lei Feng(Authors)
  • 2020(Publication Date)
  • De Gruyter

    (Publisher)

  Interruption 1 2 3 Figure 7.44: Interruption and tracing by segments. Context of function 3 Context of function 2 Context of function 1 Context of main function Saving order Restoring order 1 2 3 4 When a program crashes, we can quickly locate the function in which error occurs by checking information in the call stack stack Figure 7.45: Record of execution path. 296 7 Execution of programs We have discussed the methodology of debugging and now we are going to intro-duce how to apply these strategies in an IDE. 7.5 Debugging tools In the world of software, inspection and repairing tools like corkscrew or multimeter no longer work. They are replaced by debugging tools with the debugger as the core. – Software Debugging, Yinkui Zhang Debugging is of vital importance to software. Inspection tools in the world of soft-ware are debugging tools. Using the right debugging tools properly can largely in-crease the efficiency of finding bugs. 7.5.1 Functions of debugger in IDE Typically, programs are executed continuously. However, debugging can control the pace of program execution. Execution of a program can be paused, done step by step, or done with jumps. When a program is paused, we can inspect its status. The debugger provides functions like controlling execution pace or inspecting exe-cution status in IDE. More specifically, it traces and records how the CPU executes a program and takes snapshots of this dynamic process for programmers to inspect and analyze as shown in Figure 7.46. By controlling the execution pace, the debugger controls the number of lines exe-cuted in each step so that programmers can better observe the execution path. Stepwise execution uses a line of code or a function as a step in program execution. In contrast, jumping execution can run a program to the cursor or breakpoints set by programmers. Stepwise execution is an effective method of diagnosing dynamic characteristics of software.

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  How to Write Good Programs

  A Guide for Students

  • Perdita Stevens(Author)
  • 2020(Publication Date)
  • Cambridge University Press

    (Publisher)

  112 9 How to Debug Your Program • single-stepping – that is, letting the program execute one line at a time, e.g. so that you can check which way it goes at an if statement; or • examining the values of variables. A little exploration of the interface will probably reveal how to use these. Many debuggers have lots of more sophisticated features, but you don’t need them for now. When you do feel like investigating, see if there’s a tutorial for the specific debugger you’re using. To get maximum benefit, you need to learn not just the mechan- ics of using a debugger, but also how to use a debugger effectively. Forming a hypothesis first, and then testing it, is a useful technique here. For example, if you are about to step through a line that calculates a value, first ask yourself what you expect the value to be, then do the step and check whether it is. If you just wait for some- thing surprising to happen, it’s remarkably easy not to notice where the trouble begins. It’s fine, of course, to run the debugger several times, first to get an overview of what’s happening, and then, more carefully, to understand important sections of it in detail. Changing the Program to Understand It What can you do if you can neither find a usable debugger, nor get your program to print an informative string when it gets to an infor- mative place in the computation? You could consider rewriting it into more inspectable pieces, to understand what’s going on. We are not talking, here, about the kind of restructuring that improves your program overall. This is not a good time to under- take that kind of work: since you are starting with a program whose behaviour you don’t fully understand, changing it radically may leave you more confused. It is better to make minimal, careful changes at this stage, and accept that you may need to undo them after you have understood the bug.

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  Reverse Engineering Code with IDA Pro

  • IOActive(Author)
  • 2011(Publication Date)
  • Syngress

    (Publisher)

  87 Chapter 5 Solutions in this chapter: ■ Debugging Basics ■ Debugging in IDA Pro ■ Use of Debugging while Reverse Engineering ■ Heap and Stack Access and Modification ■ Other Debuggers ˛ Summary Debugging 88 Chapter 5 • Debugging www.syngress.com Introduction Debugging is the act of locating bugs in software. Generally this is done by developers as bugs are worked out of their software. Debugging can take many forms. Beginning programmers often use output as a rudimentary form of debugging. This output can be printf statements in the case of C. The most popular story on the use of debugging involves actual bugs. The origin of the use of “bug” to refer to a programming mistake is attributed to Admiral Grace Murray Hopper. A moth got caught in one of the relays from the Harvard University’s Mark II computer. The removal of the moth was coined debugging . Debuggers are programs themselves that run and monitor the execution of other programs. The debugger can control and alter the execution of the target program. Memory and variables can be monitored and altered as well. Debugging Basics Debuggers are an essential tool in the reverse engineer’s toolbox. The ability to perform runtime analysis speeds up program understanding and reverse engineering. Certain tasks are easier within a debugger. Call chains can be watched instead of guessed. Tracking indirect calls is much easier during debugging. A call through a register is an example of an indirect call. IDA Pro’s static analysis tracks indirect calls in a very limited fashion. Cross references are not created. Debugging allows us to watch, observe, and guide our reverse engineering. We do not want to reverse engineer entire programs, but rather the interesting parts. Tools & Traps … User mode vs. kernel mode debuggers User mode debuggers operate on processes. They themselves are standard processes and as such are limited to what memory can be accessed.

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  The Art of Programming Embedded Systems

  • Jack Ganssle(Author)
  • 2012(Publication Date)
  • Academic Press

    (Publisher)

  You can enter and test code incrementally. While this violates almost every tenet of structured programming, it is a valu-able way to prove an algorithm's correctness. By experimenting in C, you may be able to port your results directly to the final product's code. However, be wary of using your experimental code in a real product. If 6 6 4. Design for Debugging you end up hacking it to death to make the algorithm work, it's gener-ally a good idea to recode first, and then port. Debugging Tools Software complexity and costs are spiraling. Product development cy-cles are often measured in man-decades or even -centuries. The dearth of competent software engineers has driven salaries up; the combina-tion of long engineering cycles and high salaries creates an insatiable demand for software productivity tools. While experts argue the merits of CASE technology to solve the front end (software design) problem, a number of effective methods for eliminating bugs in the back end have evolved. Typically, 50% or more of the development effort is consumed by debug and test. Every improvement in debugging productivity will net large dollar and time savings. Debugging code in an embedded system is far more tedious and challenging than on a large mainframe. An embedded system rarely has a facility for operator interaction. The program, being hard-coded in ROM, is fixed and almost inaccessible. Most embedded processors have no inherent debugging facilities. In the past a rather casual approach to debugging was both common and adequate. Once the code was complete, the software engineer spent months isolating bugs using whatever tools were at hand. The process was often a game of wits, earning programmers reputations as practi-tioners of a mysterious art. Programming is now recognized as a com-plex activity to be managed like any other aspect of business.

  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.