Back to Basics: Debugging in C++ - Mike Shah - CppCon 2022

---

Back to Basics: Debugging in C++ - Mike Shah - CppCon 2022

I always tell my students, the debugger is your 'get out of jail free card' when working on a project. I say the same thing to professionals, debuggers are your 'get out of free jail card'. The reality is that programmers spend the majority of their time debugging as opposed to writing new code. Unfortunately many programmers do not learn how to use a debugger, or otherwise how they should approach debugging. In this talk I am going to show you how to debug C++ code, starting from the very basics and then demonstrating how a debugger like GDB can be used to help you track errors in CPU code. Attendees at this talk will learn names of debugging techniques (e.g. delta debugging), and I will demonstrate several debugging tools (stepping through code, capturing backtraces, conditional breakpoints, scripting, and even time traveling!) to demonstrate the power of debuggers. This is a beginner friendly talk where we are going to start from the beginning, but I suspect I may show a trick or two that folks with prior experience will appreciate.
---

Mike Shah

Mike Shah is an Associate Teaching Professor at Northeastern University in the Khoury College of Computer Sciences. His primary teaching interests are in computer systems, computer graphics, and software engineering. His research interests are related to performance engineering (dynamic analysis), software visualization, and computer graphics. Along with teaching and research work, he have juggled occasional consulting work as a 3D Senior Graphics Engineer in C++.

Mike discovered computer science at the age of 13 when googling ”how do I make games”. From that google search, Mike has worked as a freelance game developer, worked in industry for Intel, Sony Playstation, Oblong Industries, and researched at The Ohio Supercomputer Center to name a few. Mike cares about building tools to help programmers monitor and improve the performance of realtime applications– especially games. In Michael’s spare time he is a long distance runner, weight lifter, and amateur pizza maker.
__

#cppcon #programming #debugging

[万宇阳]

I always avoided to make use of gdb tui mode because I thought the tui was buggy until I saw this video and learned that there is refresh command or ctrl-l to refresh the layout. Appreciated this talk!

[natedoggstyle]

The talk I had I wish I had gotten during my first software engineering job after college.

[edwardli]

Mike Shah was an MVP professor when I was at Northeastern -- can't wait to dive into th is talk!

[dmitrystelefona]

This is most back to basics i ever saw on conference ever. This one is really 101 programming in no more then month into a course, after that is useless.
Too bad, i spend much time debugging(99% i guess, like 5 lines of code per day.) and had some hopes the talk would make my life easier.

[johnmcleodvii]

In 29 years of software engineering, I have used printf debugging only a handful of times. In each of these cases the bug did not happen when the code was compiled for debug. In one case it was because the compiler initialized everything to 0 in debug, but did not do any initialization at all for release. The programmer (not me, I inherited the code) was counting on implicit 0 initialization for pointers. 2 more were multi threading problems where more that 1 printf would make the problem disappear. And the last one I still don't know why it wouldn't happen in debug mode.

In all cases, I had a manager ask why we couldn't just ship debug code.

[bunpasi]

I do web development in notepad++, because (... I have no idea why). But when I can come back to PyCharm or Visual Studio, the debugging tools are always such a relief.

[christygeorge]

Very useful, Got to learn a lot more about gdb, well explained

[ABaumstumpf]

Would be nice if we could use an interactive debugger but...
The process is interdependent on other processes, everything together managed by yet another managing-program. And most of the bugs are either obvious to the person that made the error, or they are really hard to narrow down as it only starts manifesting a lot later (incorrect data getting moved between multiple processes and into an event-queue were the actual error than happens several milliseconds later).

one such bug i created was that a data-cache was taken by value instead of reference (the cache holds the available quantity of some objects). Under normal situations that had no impact on the result so only happened rarely but ultimately it happened when the previous actions had to be undone cause some post-processing on another stream of data would show that the objective could not be reached and the actions on the cache need to be undone if possible, or the data reloaded otherwise.
Only when this routine was called repeatedly within a timeframe of 15 seconds (timeout for the cache-data), with more than 10 requests (threshold for using this extra cache) each needing a substantial number of those objects (in general the requests are expected to never fail), multiple of those requests need the same object, one of the (not the last) fails and the later request needed more objects than were available after the rollback - only in that scenario it would give a wrong result. That result was passed through several processes and queues and was then sent to another separate system that would then respond with an error to us. The entire processing could well take a second while hundreds of other requests go through the exact same path correctly.

[rafaelrodriguezcalvente]

Would it be more convinience to use gdb on the terminal or debuggin with the help of some IDE like VSC?

[broken_abi]

Yeah, why would c++ devs debug with printfs when they have gdb?


(gdb) p my_std_vector[0]
Could not find operator[].

Oh I remember why. And yes, this happens even with the -ggdb flag.

[bnk]

actually if you just press enter it repeats the last command, no need to keep typing next next next etc

[rdmeneze]

I'm spending three weeks of my life to debug a legacy code to try to document the features implemented. Think in a big C code, without comments and using K&R standard. Nightmare!

The plus is that I can't debug at my local machine. I have to connect into a remote production server and debug there.

[shashankgangrade]

Hey Mike,
Great talk, it was getting interesting around the last few slides. They went by too fast, where can I get the presentation/pdf of the same?

[yugr]

How come a talk on debugging does not mention Valgrind and sanitizers?

[simonfarre]

Great talk. Using a bit of RR would also have been magical, even for "basics". Only problem with that is that you're limited to Linux.

I've written a debug adapter for VSCode which interfaces with GDB. Sure there's cpptools. But it uses some of the problematic GDB code when it comes to static data - and it doesn't come with support for RR which Midas does. If you want to try it for vscode, it's called "Midas" and is a debug adapter for GDB, so works for things that GDB can handle. It's on the VSCode market place for extensions.

[PixelPulse]

The next gen debugger will some kind of GPT-assisted.

[Dziaji]

If the average amount of time that a developer spends debugging is 50%, the cost can't be higher than 50% because debugging is free and only costs as much as the developer is paid, and since you are paying for his time, it can't be more than 50%

[yaroslavpanych]

"doing it from a command line is good exercise"
Somebody started with budged/time costs of debugging? If find it freaking hypocritical to encourage slow and cumbersome exercise tools while aiming to reduce those costs while faster and easier to use tools exists! And that is not the question of lack functionality either!