17

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?

Thomas Dignan
  • 674
  • 2
  • 5
  • 15

4 Answers4

33
  • 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.
Robert Anton Reese
  • 936
  • 9
  • 12
  • 12
    +10 "Go have a look over your clients shoulder", clients don't think like us and usually do things differently than we do. – Echo says Reinstate Monica 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
  • I don't know how many times I've gone to sit with the client and found that they're doing something they aren't reporting in their reproduction steps. "Oh, obviously I'm clicking THAT button, don't you always click that?" I had a bug once that involved saving a record which was created from a copy, except the report never mentioned copying, only saving a record. If this kind of information is lost in the report, the ONLY way to get it back is to have the user perform the bug in front of you. – Sprague Apr 07 '15 at 09:23
3

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!

Macneil
  • 8,223
  • 4
  • 34
  • 68
1

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.

Mike Crawford
  • 836
  • 4
  • 6
  • 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. – Mike Crawford Aug 22 '11 at 19:28
1

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.

Nicholas Smith
  • 1,621
  • 10
  • 11