Nsryjdtyk

This is intended to be a general purpose question to assist new programmers who have a problem with a program, but do not know how to use a debugger to diagnose the cause of the problem.

This question covers two classes of more specific question:

• When I run my program, it does not produce the output I expect for the input I gave it


• When I run my program, it crashes and gives me a stack trace. I have examined the stack trace, but I still do not know the cause of the problem because the stack trace does not provide me with enough information.

A debugger is a program that can examine the state of your program while your program is running. The technical means it uses for doing this are not important for understanding the basics of how to use a debugger. You can use a debugger to halt the execution of your program when it reaches a particular place in your code, then examine the values of the variables in the program. You can use a debugger to run your program very slowly, one line of code at a time (called single stepping), while you examine the values of its variables.

By doing this you can discover whether a variable has the wrong value, and where in your program its value changed to the wrong value.

Using single stepping you can also discover whether the control flow is as you expect. For example, whether an if branch executed when you expect it ought to be.

The specifics of using a debugger depend on the debugger and, to a lesser degree, the programming language you are using.

• You can attach a debugger to a process already running your program. You might do if your program is stuck.




• In practice it is often easier to run your program under the control of a debugger from the very start.




• You indicate where your program should stop executing by indicating the source-code file and line number of the line at which execution should stop, or by indicating the name of the method/function at which the program should stop (if you want to stop as soon as execution enters the method). The technical means that the debugger uses to cause your program to stop is called a breakpoint and this process is called setting a breakpoint.




• Most modern debuggers are part of an IDE and provide you with a convenient GUI for examining the source code and variables of your program, with a point-and-click interface for setting breakpoints, running your program and single stepping it.




• Using a debugger can be very difficult unless your program executable or bytecode files include debugging symbol information. You might have to compile (or recompile) your program slightly differently to ensure that information is present.

I want to add that a debugger isn't always the perfect solution, and shouldn't always be the go-to solution to debugging. Here are a few cases where a debugger might not work for you:

• The part of your program which fails is really large (poor modularization, perhaps?) and you're not exactly sure where to start stepping through the code. Stepping through all of it might be too time consuming.


• Your program uses a lot of callbacks and other non-linear flow control methods, which makes the debugger confused when you step through it.


• Your program is multi-threaded. Or even worse, your problem is caused by a race condition.


• The code that has the bug in it runs many times before it bugs out. This can be particularly problematic in main loops, or worse yet, in physics engines, where the problem could be numerical. Even setting a breakpoint, in this case, would simply have you hitting it many times, with the bug not appearing.


• Your program must run in real time. This is a big issue for programs that connect to the network. If you set up a breakpoint in your network code, the other end isn't going to wait for you to step through, it's simply going to time out. Programs which rely on the system clock, e.g. games with frame skip, aren't much better off either.


• Your program performs some form of destructive actions, like writing to files or sending e-mails, and you'd like to limit the number of times you need to run through it.


• You can tell that your bug is caused by incorrect values arriving at function X, but you don't know where these values come from. Having to run through the program, again and again, setting breakpoints farther and farther back, can be a huge hassle. Especially if function X is called from many places throughout the program.

In all of these cases, either having your program stop abruptly could cause the end results to differ, or stepping through manually in search of the one line where the bug is caused is too much of a hassle. This can equally happen whether your bug is incorrect behavior, or a crash. For instance, if memory corruption causes a crash, by the time the crash happens, it's too far from where the memory corruption first occurred, and no useful information is left.

So, what are the alternatives?

Simplest is simply logging and assertions. Add logs to your program at various points, and compare what you get with what you're expecting. For instance, see if the function where you think there's a bug is even called in the first place. See if the variables at a start of a method are what you think they are. Unlike breakpoints, it's okay for there to be many log lines in which nothing special happens. You can simply search through the log afterwards. Once you hit a log line that's different from what you're expecting, add more in the same area. Narrow it down farther and farther, until it's small enough to be able to log every line in the bugged area.

Assertions can be used to trap incorrect values as they occur, rather than once they have a visible effect to the end user. The quicker you catch an incorrect value, the closer you are to the line that produced it.

Refactor and unit test. If your program is too big, it might be worthwhile to test it one class or one function at a time. Give it inputs, and look at the outputs, and see which are not as you're expecting. Being able to narrow down a bug from an entire program to a single function can make a huge difference in debugging time.

In case of memory leaks or memory stomping, use appropriate tools which are able to analyze and detect these at runtime. Being able to detect where the actual corruption occurs is the first step. After this, you can use logs to work your way back to where incorrect values were introduced.

Remember that debugging is a process going backwards. You have the end result - a bug - and find the cause, which preceded it. It's about working your way backwards and, unfortunately, debuggers only step forwards. This is where good logging and postmortem analysis can give you much better results.