Greg (gregstoll) wrote,

  • Mood:

Software development tools I'm grateful for

This morning I tracked down a bug with a data breakpoint. Turns out, it was a very stupid bug that I introduced myself last week, so it was a bit like cutting a piece of paper with a chainsaw. But it got me to thinking - I'm really glad we have a full shed of chainsaws when we need them! Here are the tools I use when developing software that I'm most grateful for, with brief descriptions:

- Breakpoints: OK, this is pretty basic, but many of the later things are built on this. Being able to say "stop on this line of code and let me see the values of stuff", as well as single-stepping through code, is good enough to track down most of the easy bugs I come across.

- Conditional breakpoints: Like breakpoints, but you can set a condition that gets evaluated each time and only stops if it's true. Very useful if you have to set a breakpoint in high-traffic areas of code, but you only care about a particular VI that's being processed.

- Data breakpoints: Like breakpoints but more awesomer! Seriously: you give it an address and the program will stop immediately when that value is changed. Very useful for tracking down memory corruptions, or just "what stupid code is stomping on my variable?" type situations. Slows down execution a bit, but it's irreplaceable when you need it.

- Tracepoints: Something I only learned about last month, but in Visual Studio you can configure a breakpoint to output something to the debug window instead of actually stopping. This is invaluable in tracking down weird race conditions and tricky timing problems where actually breaking into the debugger will stop it from happening.

- Source control: Pretty fundamental, but being able to see when a line of code was last changed is occasionally very helpful. (plus, of course, being able to undo whole checkins at once, etc., etc.)

- Remote debugging: This still seems magical to me: you can copy over a small program to any machine, then from my computer I can attach to it and debug it as if it was running on my machine! Great for when a bug requires a bunch of other stuff installed to happen. Made even better by:

- Symbol server/pdb files: We archive all of our official build symbols. So, that means, as long as a remote computer is using an official version of LabVIEW, I can debug it and get symbols to see what function we're broken into, etc. Not always perfect (it can be annoying if your source isn't the same as when the executable was built), but makes my life much much easier.

- VMWare images: a great alternative to needing a physical machine to reproduce a problem on, in case you need a bunch of extra stuff installed. Even better in that it makes possible:

- Replay debugging: This is seriously amazeballs. On a VMWare image, you can try to reproduce a problem. When you succeed, you've basically recorded everything that's happened up to that point, and so you can essentially step back in time to see what went wrong. Think Prince of Persia, but without needing that pesky sand. (also: apparently it makes things kinda slow) I have not had the opportunity to use replay debugging, but I hope I do some day because: wow!

Being grateful for things makes you happy. I'm pretty happy now. What are you grateful for? (or, what did I miss in my list?)
Tags: essay, programming
  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded