2 ms·
Adjacent comment pretty much explained it. Sometimes it's printf, sometimes it's subtle tweaks to program behavior in strategic places, sometimes it's adding as
by fc417fc802 1y ago
Adjacent comment pretty much explained it. Sometimes it's printf, sometimes it's subtle tweaks to program behavior in strategic places, sometimes it's adding asserts (that might very well call functions not intended for public consumption).
I always start debugging by coming up with a theory about why the observed behavior occurred. The fastest way to validate that is generally one or two tiny changes to the program.
I only break out the debug tooling for the serious stuff that has me scratching my head in confusion. Either because the behavior has me thinking "there's no way that's possible" (spoiler: almost always memory corruption) or because I'm segfaulting in a shared library that I didn't compile or because I'm well into some obvious badlands with concurrency or memory corruption or the like.
- throwaway2037 1y agoWhat are your primary languages? Even in 2025, C & C++ debuggers are light years ahead of 15 years ago. And Java / DotNet debuggers are mind-blowing they are so good, plus "memory corruption" isn't possible (that I know) in vanilla code that runs in a VM. I almost never bother with your techniques anymore.