Live vs. offline debugging

Question

I've been trying to find the difference between these 2 types of debugging, but couldn't find it anywhere (been googling almost 30 minutes), so I'm asking here: What's the difference between live vs. offline debugging? What do people mean when they say a debugger is "live" vs. "offline"?

Answer 1

"Online" debugging is the normal process:

• Tell the debugger to tell the program to step forwards;
• Look at what the program state is at the moment;
• Set a breakpoint for the future;
• Tell the debugger to simply run the program;
• If the breakpoint 'fires', have a look at the program state now.

There are two ways to "offline" debug:

1. You can take your source code and manually step through what the processor ought to be doing, watching for unexpected program paths.

   Note if you do this, you need to diligently not "know" what the processor is "supposed" to do and just do that: you need to honestly obey the code as though you were the computer. Often you get other people, who don't know the code, to do this instead of you.

2. You take the result of a run-log, usually captured by a hardware probe, and use the debugger to "post mortem" the run.

The latter usually requires a processor that will transmit what it is doing out a "Trace" port (not all have this), and a hardware device (like a probe) connected to the Trace port to capture the data. That probe then communicates with a debugger, which takes the data and presents it to the programmer. The programmer can work backwards and forwards through this Trace log, and see the execution path that the code actually took, rather than the code the programmer thought it should take.

Some processors not only transmit what instruction they're currently processing, but also what data they read or wrote while doing this. A more sophisticated debugger can take this extra data and provide a 'snapshot' of the system at any time during the run, allowing the programmer to analyse why the code behaved the way it did.

The reason that it is called "offline" is because once the log has been captured, you can disconnect and power down the target, and look at the saved log at any time in the future without still being connected to the probe or processor.

Answer 2

Debugging types

There are several ways of debugging that can be distinguished:

1. live debugging vs. post mortem debugging (what you call "offline" debugging, also called "dump debugging")
2. kernel debugging vs. user mode debugging
3. local debugging vs. remote debugging

which give 8 combinations in total.

For live debugging, you can distinguish between invasive debugging vs. noninvasive debugging.

Live debugging vs. offline debugging

In live debugging, the program is running and the debugger is attached to it. This means you can still interact with the program. You can set breakpoints, handle exceptions that would normally cause the program to terminate, modify the memory etc.

The downside of live debugging is its temporal/fluent nature. If you enter a wrong command or step too far, the situation is gone and might not be repeatable.

I mentioned that there are 2 sub-modes for live debugging: invasive and noninvasive debugging: in noninvasive debugging, the debugger does not attach to the target application. It suspends all of the program's threads and has access to the memory, registers, and other such information. However, the debugger cannot control the target.

In post mortem debugging, someone has captured a memory dump of a running program at a certain point in time. In many cases this is done upon a specific event, eg an unhandled exception that causes the program to terminate. Since the memory dump is a file on disk, you can analyze it as often as you want and you get the exact same situation.

The downside if post mortem debugging is, of course, that the program is not running, you can't interact with it and it's very hard to find out what happens next.