Debugging nightmares: How many of these common
debugging mistakes are keeping you up at night?

March 08, 2017 | BY: Tammy Carter

Download PDF

If you are a software developer, long nights filled with infinite coffee, heavy eyes, and hair pulling is not a foreign concept. Every time you think you’re ready to turn off the lights and shut down the project, you find another bug creep out to taunt you. It looks familiar, like you’ve seen it scurrying on the floor in previous nights, but you can’t quite remember how you got rid of it last time.

Sound about right?

Most software bugs fall into three broad categories: The first is straightforward and repeatable. Due to its nature, it is the easiest to find and to fix. The next one plays catch-me-if-you-can, and hides when you try to trap it. For example, every developer has tried to debug a problem by putting in “just a couple of ‘print’ statements”, and amazingly the code starts working. Then, a few more ‘print’ statements are added and the problem re-emerges but dressed in totally different symptoms. The final bug is the monster that haunts our nightmares, the one of such complexity and obscurity that it appears to be truly random and not following any discernable pattern. It might only happen once a week after running mode A and then mode B for a thousand times in a complex sequence, under a full moon, when you go to get a drink and a cold piece of pizza. This is not only true in high performance embedded computing, but also in any type of software debugging. All these bugs create problems, whether they end in dismal failure, incorrect results, a hard crash, or the program lost in the weeds.


When you look back at the different types of bugs that have haunted your late nights, how many of these sleepless sessions could have been avoided? How many of these bugs could have been resolved more easily?

1. Did you even check if this is a problem you’ve solved before?

When software debugging, bursts of creativity and intuition must work in harmony with rational problem-solving skills and the best available tools for the job. Often developers get so caught up in the problem at hand, they forget to step back and think: “Where have I seen this before?. Have I solved a similar bug that could lend some insights for this?”. Instead, it is easy to trap yourself in a whirlwind of trial and error on a quest to come out on top.

2. If you have seen it before, did you remember to keep a log?

Sometimes the bug will trigger a memory so faint in your mind, you need to dust off the files before being able to pinpoint when and where you saw a similar bug. Once you remember, you check your logbook only to find you never actually made notes on it. That is, if you’re lucky enough to remember where you left your logbook.

Pro tip: In the world of high performance embedded computing (and also high performance computing), programs like Allinea DDT provide a digital logbook that automatically records the entire debugging session. For each stop in the program’s execution, the reason and location is recoded along with the parallel stacks, variables, and tracepoints, which is a scalable ‘print’ alternative. The only exercise left for the user is recording the hypothesis, resulting observations, and concluding using the annotation option.

3. Are you wasting time chasing bugs that could be resolved while you sleep?

What did we just say? Yes – those bugs that are the worst of the worst can actually be solved while you sleep! Applications like Allinea DDT offer an offline debugging mode where the debugger directs both the running of the code and the storing of results without user intervention.

This allows the system to collect data overnight or however long it takes the problem to occur. This offline mode supports a full set of tools such as tracepoints, memory debugging aids, and even breakpoints. In this mode, the debugger can also compile snapshots of the program state including the stacks and selected variables. The snapshots can be triggered periodically or by sending a signal from another terminal window to the DDT front-end process. The final report produced by the offline session consists of four sections; messages, tracepoints, memory leak status, and the output complete with timestamps.

Want to find out other ways debugging tools can help you get a full night’s rest AND shining recognition at the office? Read more about Zen and the Art of Software Debugging in our high performance embedded computing white paper available here. You’ll learn about:

  • Approaches to debugging
  • The three categories of software bugs
  • Tracepoints, sparklines, and watchpoints
  • Memory overwrites


Author’s Biography

Tammy Carter

Senior Product Manager – OpenHPEC

Tammy Carter is the Senior Product Manager for OpenHPEC products for Curtiss-Wright Defense Solutions, based out of Ashburn Virginia. She has over 20 years of experience in designing, developing and integrating real-time embedded systems in the Defense, Communications and Medical arenas, and a M.S. in Computer Science.

Share This Article

  • Share on Linkedin
  • Share on Twitter
  • Share on Facebook
  • Share on Google+
Want to add a comment? Please login
Connect With Curtiss-Wright Connect With Curtiss-Wright Connect With Curtiss-Wright


Contact our sales team today to learn more about our products and services.





Our support team can help answer your questions - contact us today.