Debugging

6 Key excerpts on "Debugging"

• 

  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

  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
• 

  No longer available |Learn more

  Learn Python Programming

  A beginner's guide to learning the fundamentals of Python language to write efficient, high-quality code, 2nd Edition

  • Fabrizio Romano(Author)
  • 2018(Publication Date)
  • Packt Publishing

    (Publisher)

  Debugging and Troubleshooting

  "If Debugging is the process of removing software bugs, then programming must be the process of putting them in." – Edsger W. Dijkstra

  In the life of a professional coder, Debugging and troubleshooting take up a significant amount of time. Even if you work on the most beautiful code base ever written by a human, there will still be bugs in it; that is guaranteed.

  We spend an awful lot of time reading other people's code and, in my opinion, a good software developer is someone who keeps their attention high, even when they're reading code that is not reported to be wrong or buggy.

  Being able to debug code efficiently and quickly is a skill that every coder needs to keep improving. Some think that because they have read the manual, they're fine, but the reality is, the number of variables in the game is so great that there is no manual. There are guidelines one can follow, but there is no magic book that will teach you everything you need to know in order to become good at this.

  I feel that on this particular subject, I have learned the most from my colleagues. It amazes me to observe someone very skilled attacking a problem. I enjoy seeing the steps they take, the things they verify to exclude possible causes, and the way they consider the suspects that eventually lead them to a solution.

  Every colleague we work with can teach us something, or surprise us with a fantastic guess that turns out to be the right one. When that happens, don't just remain in wonderment (or worse, in envy), but seize the moment and ask them how they got to that guess and why. The answer will allow you to see whether there is something you can study in-depth later on so that, maybe next time, you'll be the one who will catch the bug.

  Some bugs are very easy to spot. They come out of coarse mistakes and, once you see the effects of those mistakes, it's easy to find a solution that fixes the problem.

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  Beginning Linux Programming

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

    (Publisher)

  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 differ- ently 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 pro- gram. Before you start programming (or designing), make sure that you know and under- stand 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 - 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

  Hardware-dependent Software

  A Classical Approach

  • Thomas Lehmann(Author)
  • 2017(Publication Date)
  • Books on Demand

    (Publisher)

  The gained knowledge often leads to a refinement of the design (compare Fig. 7.8) or is required to create a driver design at all. In the design areas with a sufficient knowledge base, the implementation of features can fill the initial driver frame as a top-down approach. As driver are crucial systems, following coding styles and working with a version control system like Git[ 10 ] should be taken for granted for a professional developer (compare for instance [ 40 ]). The test should not only be performed on the developer machine, those have aggregated special settings and configurations over time. The distribution and installation procedure is a base infrastructure like logging, so it should be taken care of right from the beginning. The automated installation process can than be used to distribute the current version to test machines for verification. So the installation procedure a a customer site becomes part of the verification process. Approaches for test and verification are discussed later in Sec. 7.3 after a discussion on Debugging. 7.2. Debugging Debugging is an essential part of the software development process, often neglected, as no software is error free directly from the beginning. Either due to design, programming, or documentation faults software defects are simply there, but obviously shouldn’t be. Tracking down to the root cause of the error, the real defect, is what is usually called Debugging. A system changes from a sane state due to a defects into a state, where the system fails (see in [ 77 ]). Debugging is the isolation/separation of components and code fragments in a causeand-effect chain and cross-checking the expected behaviour against the observed behaviour to narrow down the defect location

  Sign up to read

  Learn more about book