How to Break Your Friend's Code

Nightmare Invisible Repaint MouseMove Bug on Elms Street

Noticias externas — Sun, 26 Aug 2007 07:44:43 GMT

Over this last week I had to debug two issues. If you’re a college student and read this blog, you would

Nightmare Invisible Repaint MouseMove Bug on Elms Street

CoolBeans: From College to Industry — Sun, 26 Aug 2007 04:01:06 GMT

Over this last week I had to debug two issues. If you’re a college student and read this blog, you would

How to be a Debugging Ninja!

Noticias externas — Tue, 31 Jul 2007 10:39:23 GMT

How many times have you had someone come up to you with a problem that they couldn’t describe? And if

How to be a Debugging Ninja!

CoolBeans: From College to Industry — Tue, 31 Jul 2007 10:22:10 GMT

How many times have you had someone come up to you with a problem that they couldn’t describe? And if

re: How to Break Your Friend's Code

Chris Becker — Fri, 20 Jul 2007 22:21:50 GMT

Hi Nektar,

Great question! This is something I'd like to cover further in a another post, but somethings that you can do if you know the location of a problem, but not specifically what is happening you can "step through" the code.

In Visual Studio, place a break point at the beginning of the offending function. Then hit "F10" to run only the next line. You can also use the Watch window to watch as variables change value as you step over lines. Stepping through is instrumental in finding either code flow problems (an if statement is or is not getting hit correctly).

You can do a bit of "reversing time" by dragging the program counter to a previous point in a function. This doesn't reverse variable states, but it does let you execute the same piece of code again (or skip a piece of code later on). Click on the yellow arrow and drag it around while debugging in VS.

Visual Studio also has a "who calls me" functionality. Right click in a function "Call Browser -> Show Graph". This will help you determine who is calling your function.

You can take snapshots in a way using "When Hit". At runtime, you can print out a callstack as well to see where calls are coming from without breaking execution and print out important variables. Then look through the output at what's happening.

Though I'm sure there are special tools people have written here at Microsoft, in general I use Visual Studio.

We do have ways of setting up automation, whether it's through the object model of the application or by simulating user input. If we have a difficult problem we need to repro (like a threading issue) we can setup a scenario that we know the problem occurs in and run it a 1000 times until it hits. Then attach a debugger and see the state of the program.

We also get crash dumps from user's machines (any time you hit "Send Error Report") and this gives us the state of a machine at the time it crashed. Here there is no history and no way to step backward or forward, we just have a picture. Determine the problem here can be very tricky and it helps to have many dumps of the same problem. However, we are able to determine the highest hitting crashes and fix those with a hotfix or a service pack.

Hopefully that answers your questions, I will try and post more on good debugging skills.

-Chris

re: How to Break Your Friend's Code

Nektar — Fri, 20 Jul 2007 16:14:01 GMT

This is all well, but what if you don't know what causes a bug but only the location where it manifests itself. This means that even if you set a break-point at the position that the bug is apparent or around it, you still need to go backwards and try to figure out what might have caused it. This means that you will need to place break-points in various places guessing on the possible route that the program took to reach the point where the bug manifested itself. If the code paths leading to this point are a few then all is well but if the code paths are dynamic, multiple and data dependent then tough luck. You don't know where to break. And if the program exhibits the bug only under very rare or difficult to reproduce senarios then double tough luck. How better it would have been if Visual Studio provided a way to go back in time and check what the application has executed before hitting a break-point, including function call history (not only the current stack), global variable changes, etc. With a trace-point I need to guess where and what to look for, if VS could go back in time, like the ability to take snap-shots then it would have been better.

Questions for you:

1. How do you handle this situation at Microsoft? Do you have special tools?

2. How do you repro difficult senarios, like run an application to a specific point of execution in an automated manner? For command-line applications that might be easy but what about gui or other applications requiring user interaction?

Thanks.

re: How to Break Your Friend's Code

Chris Becker — Fri, 20 Jul 2007 09:54:00 GMT

Yes, but speed is arguably a low concern while debugging. The idea is to identify a problem, not demonstrate your applications performance.

That said I once placed a break point in a "new" override looking for a specific address allocation. Sloth city.

re: How to Break Your Friend's Code

hack_tick — Fri, 20 Jul 2007 09:45:12 GMT

I remember having a conditional break point always reduced speed of execution for my Win32/C application.