Debugging C++ on Linux, twenty years on
You probably got here from a link written between 2006 and 2012, pointing at a debugger that no longer ships. It's worth telling you what happened to the argument it was making.
This domain used to sell ZeroBUGS, a commercial C++ debugger for Linux. The full story of that is on the domain history page, including who wrote it and why we have nothing to do with him. What that page deliberately doesn't do is answer the question you actually had when you clicked. So this page does.
The 2006 site made a specific, checkable claim: Linux had plenty of front ends for GDB and very few actual debugger engines, and GDB's several hundred thousand lines made it open in theory and closed in practice. Was that right?
The product lost. The argument won.
ZeroBUGS went quiet around 2013. Nobody uses it. But read its feature comparison table today and it reads less like a dead product and more like a roadmap somebody else shipped. Here's every row, then and now.
Graphical interface
2006: Zero yes, GDB no. The archived table made this its headline row.
2026: Settled, and not the way either side expected. GDB and LLDB both speak the Debug Adapter Protocol, so the front end is now the editor you already use.
A C++ API and SDK
2006: Zero yes, GDB no. The pitch was a debugger you could build on, not just drive.
2026: LLDB is exactly that. It ships as a library with a stable C++ and Python API, and Xcode, CLion and the VS Code extensions are all clients of it.
Runtime modularity, plugins loaded on demand
2006: Zero yes, GDB no.
2026: LLVM made this normal. LLDB loads language and platform plugins the same way.
Scriptable in Python, including custom data structure visualization
2006: A paid differentiator in the 2.0 feature list.
2026: GDB has embedded Python since 7.0 in 2009, with pretty printers for libstdc++ shipped by default. Free, and the thing everyone uses.
Memory watchpoints, conditional breakpoints, expression evaluation
2006: Listed as features worth 39.95 USD a year.
2026: Table stakes in every debugger on this page.
Debugging forked processes and pthread applications
2006: Called out specifically, with debug events disableable per thread.
2026: GDB handles both, and this is still where most people get stuck. The hard part moved from "can the tool do it" to "can you reproduce it twice".
Four of those six were absorbed into free tools within a decade. That's the pattern this blog keeps running into: a paid tool identifies a real gap, charges for it, and the gap closes underneath it. The people who bought a 39.95 USD license in 2008 weren't wrong about what was missing. They were wrong about who'd fill it.
What you'd actually reach for now
GDB 17.2, released 10 May 2026
The engine ZeroBUGS was arguing against, still here, and it absorbed most of what the argument was about. Python scripting, pretty printers, reverse execution of its own.
LLDB 21.1.8, released 16 December 2025
The debugger-as-a-library that the 2006 comparison table said did not exist. It arrived from LLVM rather than from a 39.95 USD product, which is the part worth sitting with.
rr record and replay, Linux only
Records an execution and replays it deterministically under GDB, forwards and backwards. The one genuinely new idea since 2006, and the answer to the pthread and fork problem that no feature list solves.
If you only take one thing from this page, take rr. Every other tool here answers "what is the program doing right now". rr answers "what did it do that one time", and that's the question that eats weeks. The 2006 feature lists, ZeroBUGS and GDB alike, had no row for it because nobody had thought of it yet.
The uncomfortable part
A debugger that shipped for eight years, had paying customers, got recommended on Stack Overflow and listed by Valgrind, and was written by someone who wrote for the C/C++ Users Journal, still ended up as a domain somebody else bought. Being good and being remembered turn out to be almost unrelated.
I keep this page because I think the opposite habit is worse. The usual move is to buy a domain with history, redirect everything to the homepage, and let the old links quietly stop meaning anything. That converts slightly better and it destroys the only thing those links carried, which was a specific answer to a specific question somebody asked in 2009.
Where this goes next
C++ debugging stays on this blog's beat, framed the way everything here is framed: not how to use a tool this week, but what a tool costs you over ten years and what happens when it stops shipping. If you want the domain's own history first, it's on the domain history page.