One of the great things about working at Arm is meeting developers with real problems and improving their lives. When you have a tool that transforms the daily report to the boss from “still fixing that bug” to “developing new code” - you’ve just made someone happy. In fact, you probably made at least two people happy.
Not every developer knows that debugging tools exist - and some of us may be pretty experienced at debugging, but still won’t know every trick in the box. There are those who say they do not need to use debuggers, but you and I know differently. There’s nothing macho about printf!
Today I’m going to highlight four features of Arm DDT to deal with crashing applications - where the debugger detects the problem instantly.
Your application dies unexpectedly, every time. Fire up Arm DDT:
ddt -start ./myapp {arguments}
This starts the debugger and your code, press the play button in the GUI - and it will run your code until the crash.
Oops - ‘y’ has a crazy value because the loop variable is wrong.
You get extra points for using Arm DDT’s offline mode - that’s a one-liner to use and summarizes the important bits of the crash in a nice, browsable HTML log file:
ddt -offline log.html ./myapp {arguments}
firefox log.html
You can read more about offline mode in our offline debugging blog.
Is the only explanation for a crash that something has changed when it should not? Constant variables changing a bit too much? Watchpoints are your answer: An instant stop as soon as a memory location changes contents.
Load the debugger and start your application. Run to a known good point by searching for the function or source file and click “run to here” in the source. Right click on the variable you think is changing - select “Add to Watches” - and press the run button.
It’s right - the value is changing there. My array index is wrong - would I ever have guessed that?
Ever seen a bug that bites for only certain problem sizes, or on certain machines? That just might be a bug with your heap memory usage. When you read or write beyond the end of an allocation of memory, bad things happen - occasionally and unpredictably. It’s occasional bugs that are harder to reproduce, and so harder to fix.
Imagine a tool that made the occasional bug happen every time? That stopped your program as soon as it happened? Arm DDT’s advanced memory debugging capabilities can do just this! All you need to do is enable the feature, a simple checkbox, and let the default settings (“fast”) do the rest. The magic “Guard Pages” will pick up the problem as soon as your application reads beyond an allocation.
Is your application crashing regularly, but unpredictably when running a large job? Simple - fire up Arm DDT - as before - but with more processes! Debugging tens of thousands of processes is quick to start - quicker than brewing a nice cup of tea in most cases (see you canreduce your caffeine intake with Arm DDT).
Run your code and wait for the crash - it’s as quick and responsive as running on a laptop!
There it is - a null pointer! Beat that, printf!