Debuggers

6 Key excerpts on "Debuggers"

• 

  eBook - ePub

  Computer-based Problem Solving Process

  • Teodor Rus(Author)
  • 2015(Publication Date)
  • WSPC

    (Publisher)

  Hence, while currently there is little one can do theoretically about the program expression with regard to the dynamic process it represents, one can feed the process with data that would help the programmer to trace all passes on which the computation can evolve. A data set that can be used to trace the computation evolution represented by a program is called a program testing package . Since every program is an expression of a specific computation there is little systematic help one can offer with respect to the program testing package construction. The inspiration should come from the structure of the computation expressed by the program and the language constructs that express the computation evolution on different passes. Branching and looping constructs offered by the programming language are usually essential for that purpose.

  16.2.2Program Debuggers

  Debuggers are software tools that are designed to take as data executable programs and run them under the control of the programmer. Hence, the debugger reads the executable program instruction by instruction and executes that instruction. Upon instruction termination, depending upon the events generated by the computation, the debugger may read and execute next instruction or tell the programmer about the events discovered. That is, every instruction executed by the debugger may generate an interrupt (a trap) and the decision to continue the execution is let to the trap handler which performs under the control of the debugger’s user. A program executed by the debugger is also said to be executed in trapping mode. Hence, the debugger is a kind of virtual monitor. Therefore, in order to develop a debugger on a given architecture that architecture must satisfy the Popek and Goldberg conditions for virtualization [Popek and Goldberg (1974)]. With respect to the debugging process the debugger must be provided with a front-end that consists of a Command Language Interpreter that allows the user to control the debugger according to conditions satisfied by the executable program performed by the debugger. The best known Debuggers are:

  • GNU Debuggers (GDB) [GDB] called GDB and named gdb, is the standard debugger for the GNU operating system. However, it is a portable debugger that runs on many Unix-like systems and works for many programming languages, including Ada, C, C++, Objective-C, Free Pascal, Fortran, Java[1] and partially others.
  • Intel Debuggers [IDB] IDB, a symbolic source code debugger used to debug C++ and Fortran programs, to disassemble and examine machine code and examine machine register values, and debug multi-threaded applications running on Linux OS. A GUI and command-line interface are available on host systems running Linux OS.

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  C++ for Financial Mathematics

  • John Armstrong(Author)
  • 2017(Publication Date)
  • Chapman and Hall/CRC

    (Publisher)

  The error messages produced by C++ when it is running can be very unhelpful. Sometimes a program will crash without providing any clue as to where in the code the problem occurred.

  A debugger is a tool that helps alleviate this problem.

  Recall that the compiler turns your C++ code into machine code. During this process, the code turns from something you wrote and understand into something that you didn’t write and don’t understand. This is a serious problem. To alleviate the problem, you can compile your code with additional debugging information that links your source code to the machine code that is being executed.

  If you have compiled your program with the necessary debugging information, then it is possible to run your program inside a debugger. The debugger will then allow you to step through your code line by line to see what is happening. It will also translate between the machine code and your source code so you can understand what is going on. In addition you can tell the debugger to pause the execution whenever an error is detected. This allows you to gather detailed information about the cause of the error. We will describe how to use the Visual Studio debugger on Windows in Section 15.2 , and how to use the GDB debugger on Unix in Section 15.3 . Other Debuggers work in a similar way. You should consult their documentation.

  15.1.5   Divide and conquer

  If you have a difficult bug to fix, it can be very useful to know the following algorithm for debugging code.

  1. By considering which of your unit tests pass and which fail, decide which area of your code contains the error.
  2. Consider how to divide the code that contains the bug into two roughly equally sized pieces. What tests can you run to determine which of these two pieces actually contains the error?
  3. Write the tests. Repeat this process until you have fixed the bug.

  The important point is that one should not look at all your code and read through it. This approach is very time-consuming and unlikely to work. Instead, this approach uses a divide and conquer

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  The Complete Edition – Software Engineering for Real-Time Systems

  A software engineering perspective toward designing real-time systems

  • Jim Cooling(Author)
  • 2019(Publication Date)
  • Packt Publishing

    (Publisher)

  Microprocessor debugging tools were developed simultaneously from two directions. At one end of the spectrum were the pure hardware items; at the other, the host software tools. Initially, these were simple and basic. With improvements and refinements, they have become complex and extremely powerful. At the same time, the boundaries have blurred between the two areas. The move is toward an integrated workstation that supports all aspects of the development work. This is typified by the modern PC-based microprocessor IDE.

  Debugging tools tell us much about the embedded software. But what they don't do is produce information about the runtime performance of the code. For instance, how fast does a section of code run? How many times are particular functions called? True – we can get at such data, but it's not always easy to do so. And, for real-time systems, runtime performance is the bottom line of the design process. In response to these needs, performance analysis tools have been produced for integration within the IDE. These represent the latest stage of software and hardware development for IDEs.

  In the following sections, the points discussed above are covered:

  Figure 11.8: The program – a journey into the unknown

  11.3 Software Debugging – What and Why?

  11.3.1 Debugging – Fundamental Concepts

  One point must be clearly understood. Software debugging is concerned with error detection in the software, not in the hardware. We assume that the hardware is fault-free. Hardware faults introduced by the software are here regarded as software errors. So, they are included in the listing of software bugs.

  A simplistic view of program execution ("journey into the unknown") is depicted in Figure 11.8 . The complete program consists of the instructions and data needed to get from A to B. Along the way, many actions are carried out. Data is collected, deposited, and modified, output devices are activated, and input devices are interrogated. When B is reached and all actions are correctly performed, we can be pretty sure that the program is correct.

  Now, how do we test this program? The simplest way is to install it on the target system and run it. In fact, unless special test tools are available, this is our only option. If the program executes as predicted, that's fine. But what if we arrive at C instead of B, carrying the wrong baggage? Or, even more confusing, what if this happens only occasionally, the program running correctly most times? Further, it is not just enough to arrive at the destination clutching the correct information. All intermediate activities and data changes must also have been done exactly as desired.

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

  Beginning Linux Programming

  • Neil Matthew, Richard Stones(Authors)
  • 2011(Publication Date)
  • Wrox

    (Publisher)

  Chapter 10 Debugging According to the Software Engineering Institute and the IEEE, every significant piece of software will initially contain defects, typically around two per 100 lines of code. These mistakes lead to programs and libraries that don’t perform as required, often causing a program to behave differently than it’s supposed to. Bug tracking, identification, and removal can consume a large amount of a programmer’s time during software development. In this chapter, we look at software defects and consider some tools and techniques for tracking down specific instances of erroneous behavior. This isn’t the same as testing (the task of verifying the program’s operation in all possible conditions), although testing and debugging are, of course, related, and many bugs are discovered during the testing process. Topics we cover include Types of errors General debugging techniques Debugging with GDB and other tools Assertions Memory use debugging Types of Errors A bug usually arises from one of a small number of causes, each of which suggests a specific method of detection and removal: Specification errors: If a program is incorrectly specified, it will inevitably fail to perform as required. Even the best programmer in the world can sometimes write the wrong program. Before you start programming (or designing), make sure that you know and understand clearly what your program needs to do. You can detect and remove many (if not all) specification errors by reviewing the requirements and agreeing that they are correct with those who will use the program. Design errors: Programs of any size need to be designed before they’re created. It’s not usually enough to sit down at a computer keyboard, type source code directly, and expect the program to work the first time. Take time to think about how you will construct the program, what data structures you’ll need, and how they will be used

  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)

  2 Understanding your app’s logic through debugging techniques

  This chapter covers

  • When to use a debugger and when to avoid it
  • Using a debugger to investigate code

  Not long ago, during one of my piano lessons, I shared the sheet music of a song I wanted to learn with my piano teacher. I was so impressed when he just played the song while reading the music sheet for the first time. “How cool is that?” I thought. “How does someone gain this skill?”

  Then, I remembered some years ago I was in a peer-programming session with one of the newly hired juniors in the company I was working for. It was my turn at the keyboard, and we were investigating a relatively large and complex piece of code using a debugger. I started navigating through the code, pressing relatively quickly the keyboard keys that allowed me to step over, into, and out of specific lines of code. I was focused on the code but was quite calm and relaxed, almost forgetting I had someone near me (rude of me). I heard this person say, “Wow, stop a bit. You’re too fast. Can you even read that code?”

  I realized that situation was similar to my experience with my piano teacher. How can you gain this skill? The answer is easier than you thought: work hard and gain experience. While practicing is invaluable and takes a lot of time, I have some tips to share with you that will help you to improve your technique much faster. In this chapter, we discuss one of the most important tools used in understanding code: the debugger.

  DEFINITION A debugger is a tool that allows you to pause the execution on specific lines and manually execute each instruction while observing how the data changes.

  Using a debugger is like navigating with Google Maps: it helps you find your way through complex logic implemented in your code. It’s also the most used tool for understanding code.

  A debugger is usually the first tool a developer learns to use to help them understand what code does. Fortunately, all IDEs come with a debugger, so you don’t have to do anything special to have one. In this book, I use IntelliJ IDEA Community in my examples, but any other IDE is quite similar and offers (sometimes with a different look) the same options we’ll discuss. Although a debugger seems to be a tool most developers know how to use, you may find, in this chapter and in chapter 3, some new techniques for using one.

  Sign up to read

  Learn more about book