Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

There's a bug in my program. Doesn't really matter what the platform is. Every so often, a row in a ListView is the wrong color. I tried setting a watchpoint for the variable that is supposed to dictate the color of the row, and it doesn't change... I am guessing it means the problem could be in the framework code. I've only witnessed it happen once.. My client has noticed it though, and wants it fixed. No idea where to start. Someone told me to artificially increase the load of the program.

What are some methods for hunting down difficult to find bugs?

share|improve this question
add comment

4 Answers

up vote 28 down vote accepted
  • Logging. Add a bunch of logging to the related module, set it to debug and get the user to send you a copy of the log when the error occurs again.
  • If you can reproduce the error, set your logger to go to the console, and try to reproduce it. Look for anomalies that only occur when the colour is wrong.
  • Back track. Find all references find any line of code that could possibly cause this issue. Then think about whether the code is doing what it should. Don't trust that your code works like you think it does. Challenge yourself - "this variable should be set to x" now test that it is. Set a conditional breakpoint. Or a print line. Or a log.
  • Grab a friend. Do some pair programing, another pair of eyes may help you.
  • Google the frame work, ask on SO, see if other people have had a similar issue. Maybe its not a bug in the framework, but a trap that people occasionally fall into.
  • This is framework dependent, but in WPF you should display the output and look for binding errors.
  • Go have a look over your clients shoulder. See if they are using the program in a different way to the way you test. Maybe they can reproduce it but aren't documenting their steps. Maybe you are assuming usage flow that is different to what the client is actually doing.
  • Take careful notes, or even better run a screen recording programing. Once the bug occurs, restart the app, and follow exactly what you did before. if you can reproduce it then you're half way there.
share|improve this answer
11  
+10 "Go have a look over your clients shoulder", clients don't think like us and usually do things differently than we do. –  Echo Aug 22 '11 at 14:01
2  
@echo /s/usually/always/ @ Robert, this is an excellent set of guidelines for all bugs, not just tough ones. Like so many things, getting down to basics is the key to success. –  corsiKa Aug 22 '11 at 15:17
add comment

Tracking down problems like these are a great opportunity to apply assertions. An assertion is simply a check on some boolean condition: "the set should be non-empty when pop is called". Many programming languages provide direct support for assertions: when enabled, assertions will abort the program or raise exceptions when they fail; when disabled, assertions are nothing more than fancy comments.

This will take some digging and re-engineering on your part. You will need to scatter through the relevant parts of the program assertions that you believe are true. You may be surprised to see that some condition is failing, when you thought it was true. When a program does something like this, it introduces an infection [in the Andreas Zeller sense], which could then lead to further infections, which might finally manifest themselves as defects [bugs].

For more tips, read through Zeller's lecture notes from his fine book, Why Programs Fail: http://www.st.cs.uni-saarland.de/edu/adebug/2002/07-tracing.pdf

And here is a link to his discussion of assertions.

Finally, given that your client regularly encounters this, this first place to start is with them! Good luck!

share|improve this answer
add comment

Use a memory debugger like valgrind, or a debugging memory allocator like Electric Fence, or on Mac OS X or the iPhone Simulator (but unfortunately not actual iOS devices), Guard Malloc.

What programming language are you using? If you told me maybe I could offer more helpful advice.

Telling us the platform would help too. For example Apple's frameworks for both Mac OS X and the iOS write to the console. Your client can use the iPhone Configuration Utility to capture console logs. If you are calling one of Apple's APIs incorrectly, it is possible that your error is logged.

If your language is C or Objective-C, you can use the CLANG Static Source Code Analyzer. It's built into Xcode now, and will work on other platforms as a command-line tool if you build it from source.

share|improve this answer
    
The clang static analyzer release notes point out that support for C++ was recently added as well. This support is apparently quite primitive, but if your code is in C++ you might still find it helpful. –  Michael Crawford Aug 22 '11 at 19:28
add comment

Artificially increasing the load isn't a bad idea, mostly because if there is a bug it'll increase the chance of it appearing, but then you need to make sure you're logging the program state constantly to work out where it's gone wrong.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.