Online GDB Debugger: Breakpoints and Stepping Tutorial

To step through code line by line in OnlineGDB, pick C or C++, click the empty space left of a line number to set a breakpoint (a red dot appears), press Debug, then press start in the debug toolbar. The program stops at your breakpoint, and the step over, step into and step out buttons move it one line, into a function, or out of a function, while the Call Stack and Local Variables panels update as you go.

This post is a hands-on walkthrough with one small C++ bug. For a broader overview of what OnlineGDB is and which languages it supports, see our general OnlineGDB guide.

What you see in the OnlineGDB debugger

As of October 2026, the OnlineGDB editor has Run, Debug, Stop, Share, Save and Beautify in the top toolbar, and a language dropdown on the right. When you press Debug, a debugger area opens below the editor with:

Control or panel	What it does	Plain GDB equivalent
start	Starts the program under the debugger	run
continue	Runs until the next breakpoint or the end	continue
step over	Runs the current line, without entering called functions	next
step into	Runs the current line, entering a called function	step
step out	Runs until the current function returns	finish
Call Stack	The chain of function calls that led here	backtrace
Local Variables	Values of locals in the current function	info locals
Display Expressions	Expressions re-evaluated at every stop	display
Breakpoints and Watchpoints	Everything you have set, numbered	info breakpoints
Debug Console tab	Type GDB commands directly	the (gdb) prompt

The button semantics come from OnlineGDB's own brief guide to its debugger; the commands behind them are standard GDB, documented in the GDB manual on stepping.

One rule to remember: the highlighted line has not run yet. When the debugger stops on line 8, line 8 is the next line to execute, so its effect is not visible in Local Variables until you step.

The example program (with a bug)

Paste this into a new C++ project. The default file is main.cpp. The program should print Sum: 66 (4 + 8 + 15 + 16 + 23), but it prints something else.

#include <iostream>
#include <vector>
using namespace std;

int sumUpTo(const vector<int>& v, int n) {
    int total = 0;
    for (int i = 0; i <= n; i++) {
        total += v[i];
    }
    return total;
}

int main() {
    vector<int> scores = {4, 8, 15, 16, 23};
    int count = scores.size();
    int result = sumUpTo(scores, count);
    cout << "Sum: " << result << endl;
    return 0;
}

Line numbers used below: int total = 0; is line 6, the for loop is line 7, total += v[i]; is line 8, and the call to sumUpTo is line 16.

Step 1: Set a breakpoint and start debugging

1. Choose C++ (or C++17/C++20) in the language dropdown.
2. Click the blank gutter just left of the number 16. A red circle appears. That is your breakpoint.
3. Click Debug in the top toolbar. The debugger area opens, but the program is not running yet.
4. Click start in the debug toolbar. Execution stops on line 16, highlighted.

Why line 16 and not line 14? If you stop on line 14 and press step into, you descend into the std::vector constructor in the standard library, which is not what you want to read. Breaking right before the call you care about saves time.

Look at Local Variables now: scores holds five elements and count is 5. result shows a junk value because line 16 has not executed yet.

Step 2: Step into the function

1. Click step into. The highlight jumps to line 6, the first line of sumUpTo.
2. Call Stack now shows two rows: sumUpTo on top, main below it. Click main to view its locals, and click sumUpTo to go back.
3. Local Variables shows v, n (5) and an uninitialised total.

In the Debug Console, the same information comes from backtrace (short form bt):

(gdb) bt
#0  sumUpTo (v=std::vector of length 5, capacity 5 = {...}, n=5) at main.cpp:6
#1  0x... in main () at main.cpp:16

The exact formatting depends on the GDB version and pretty printers, but frame #0 is always where you are now and #1 is its caller. See Backtraces in the GDB manual.

Step 3: Step over, line by line

Click step over repeatedly and watch the highlight cycle through lines 7 and 8 while i and total change in Local Variables:

Stop on line	i	total (before this line runs)
8	0	0
8	1	4
8	2	12
8	3	27
8	4	43
8	5	66

That last row is the bug. total is already 66, the correct answer, but the loop runs once more with i == 5, reading v[5], which is past the end of a five-element vector. That is undefined behavior, so the printed sum is wrong (and can differ between runs). The fix is i < n instead of i <= n.

Step over versus step into matters here: on line 8, step into would enter std::vector::operator[]. Use step over for library calls and step into only for your own functions.

Step 4: Use a conditional breakpoint instead of clicking

Stepping six times is fine for a five-element array, not for 10,000 iterations. Stop exactly where the interesting thing happens. Open the Debug Console tab and type:

(gdb) break 8 if i == 5
(gdb) continue

The program now runs until line 8 with i equal to 5, and stops there. The new breakpoint shows up in Breakpoints and Watchpoints. You can also add a condition to an existing breakpoint by number, for example condition 2 i == 5. Syntax details are in Break Conditions.

Step 5: Watch a variable change

A watchpoint stops the program whenever a value changes, without you knowing which line changes it. While stopped inside sumUpTo, type:

(gdb) watch total
(gdb) continue

Each stop prints the old and new value:

Hardware watchpoint 3: total

Old value = 27
New value = 43

A watchpoint on a local variable is deleted automatically when the function returns, because the variable no longer exists. See Setting Watchpoints, which also covers rwatch (stop on read) and awatch (read or write).

To keep a value on screen without stopping, use display:

(gdb) display i
(gdb) display total

Displayed expressions are printed at every stop (Automatic Display). To check a value once, use print, e.g. print n or p total.

Step 6: Step out and finish the run

1. Click step out (GDB: finish). The function runs to its end and the debugger stops back in main on line 16. In the console, finish also prints Value returned is ... with the return value.
2. Click step over once more so line 16 completes. result in Local Variables now holds the returned sum.
3. Click continue to run to the end. Output appears in the stdout tab.

Now change line 7 to for (int i = 0; i < n; i++), debug again, and the program prints Sum: 66.

GDB command cheat sheet for the Debug Console

Task	Command	Short form
Break at a line	break 16	b 16
Break at a function	break sumUpTo	b sumUpTo
Conditional break	break 8 if i == 5
List breakpoints	info breakpoints	i b
Delete breakpoint 2	delete 2	d 2
Next line, skip calls	next	n
Next line, enter calls	step	s
Run to function return	finish	fin
Run past the end of a loop	until	u
Show call stack	backtrace	bt
Switch to frame 1	frame 1	f 1
Print a value	print total	p total
Show all locals	info locals
Stop when a value changes	watch total

Limitations to know

• Language support for the debugger is narrower than for running code. Debug mode is built on GDB, so it is aimed at C and C++ (GDB also handles some other compiled languages). As of October 2026, the OnlineGDB page itself shows the message "Debug mode for python program is not yet supported", so for Python use pdb locally or an IDE debugger.
• Sessions time out. OnlineGDB stops a debug session after a period of inactivity, so don't leave it paused for long.
• Input must be typed when the program asks. If your code reads from cin, the debugger waits for you to type in the console at that point.
• Optimization hurts stepping. If you add flags such as -O2 under Extra Compiler Flags, lines may be reordered and variables shown as <optimized out>. Keep optimization off while debugging.
• It is a learning tool, not a full IDE. For multi-file projects, core dumps, or attaching to a running process, use GDB or LLDB locally, or a desktop IDE. You can compare options on our IDE and editor tools page.

FAQ

How do I set a breakpoint in OnlineGDB?

Click the blank area just left of the line number in the editor; a red circle marks the breakpoint. You can also type break <line> in the Debug Console after pressing Debug. Breakpoints only take effect when you run with Debug, not Run.

What is the difference between step over and step into?

Both run the current line. Step over (GDB next) treats function calls on that line as one step. Step into (GDB step) stops at the first line inside the called function. Use step into for your own functions and step over for library calls like cout or vector methods.

Why does my variable show a strange value at the breakpoint?

The highlighted line has not executed yet, so a variable it assigns still holds whatever was in memory. Click step over once and the value updates.

Can I use the OnlineGDB debugger for Python or Java?

The OnlineGDB debugger is GDB-based and works for C and C++. As of October 2026 the site shows that Python debug mode is not yet supported. Running Python or Java code works, but for stepping through it, use a local debugger such as pdb or your IDE.

Is OnlineGDB free?

Yes, the compiler and debugger are free to use in the browser without installing anything. Signing in lets you save projects to your account. If you are looking for other free developer tools, see our free alternatives directory.