Back to Basics: Debugging in Cpp - Greg Law - CppCon 2023

---

Back to Basics: Debugging in Cpp - Greg Law - CppCon 2023

Everyone knows that debugging is twice as hard as writing a program in the first place. Fortunately, there is more help available than you might have thought. GDB is much more powerful than most people realize; Valgrind and Address Sanitizer can catch many common bugs before they wreak havoc; time-travel debugging can turn even the most intractable nightmarish bugs into pussycats. This fast-paced talk is light on slides and heavy on demos to show you what's available and how to use it. Familiarity with the tools available to you is an essential part of being a great programmer; you will leave this talk at least one step closer to programming zen.
---

Greg Law

Greg is co-founder and CEO at Undo. He is a programmer at heart, but likes to keep one foot in the software world and one in the business world. Greg finds it particularly rewarding to turn innovative software technology into a real business. Greg has over 25 years' experience in innovative start-up software companies.
---

---

#cppcon #cppprogramming #cpp #debugging

[dolphin]

Great talk! Thank you, Greg. I've been watching these Back To Basics videos for years and every time I wonder how one hour talk can simplify the life of a C or C++ developer.

[CHNNELZERO]

The stuff at the end looks like gold. Can't wait to try that out.

[timhaines]

@27:28 - Adding debug information (here, DWARF) to a binary does not slow down it's runtime execution. But it can drastically increase the loading time. If you've ever launched ten thousand MPI jobs with a 4GB binary that only has 300MB of .text in it, you'll know what I mean. Separate debug information (dbo, dbz) will give you the nearly-zero overhead you are looking for.

[simonfarre]

If you are on Linux and using VSCode, using GDB becomes trivial with the "Midas" debug adapter extension. It also makes the use of RR and GDB seamless.

I just realized every single slide had "undo" on it. Kinda obvious why they won't mention RR then 😅. RR is free and open source though, undo isnt.

[Yupppi]

I think part of why this debugging talk is so good is because there's so many little commands and arguments and syntaxes and whatnot that went wrong in demonstrating the debugging, that it lead to debugging itself. And it perfectly demonstrates why you need a debugger when even in a thing you do all the time at home and at work and prepare for the demonstration, you still get some things wrong, because you're just a human. So you should probably take advantage of tools and not trust yourself.

[torstenknodt]

Thanks, great to see all the possibilities.
I worked mostly on deeply embedded systems, where you do not have executables, so this was really great.
However, from the title I expected something specific to C++, like how to debug through templates and such stuff.

[jacquesenboit]

Would be nice if chapters are listed. This way I can jump riggt into what's new to me.

[empireempire]

his attempt at using GDB is exactly why i hate to use GDB xD It's so user-unfriendly it's crazy, especially considering typical linux command line tools

[UvUtkarsh]

10:47 "especially if they talk back"
I see what you did there 😂😂😂

[MalcolmParsons]

Apparently DDD has new maintainers and ddd-3.4.0 was released on 2023/05/10

[oisyn-]

23:45 OMG the pain. I totally couldn't relate about printf debugging, that's usually only my go to when I have to deal with too much data or events such that stepping through the code doesn't make a lot of sense yet as you don't know the exact conditions to look for. Otherwise it's just a matter of pressing F5 from the IDE. I personally never worked with GDB, or maybe on a blue monday 15 years ago or something, but if that's the interface you need to deal with to just debug your code, my god I understand how you would choose to first do some printf calls instead. Is this the state of things on linux or are there better tools available? I should hope so. (Disclaimer: I've been working with Visual Studio for the past 20 years, developing for PC and game consoles)

[jimcameron]

"How many lines of code can you type in and have it work first time?"
Me: On average ... about 1/2?

[wjrasmussen]

I feel like I spend too much time bugging!

[haxhunyadi]

This is technically all good, but does not help at all when it comes to debugging. What people want is a pragmatic way of finding/reproducing errors. The sad truth is that there is no such way for most of the bugs.

[USGrantst]

I rarely debug my code, but I had to debug other people's code a lot. The most difficult cases are in two categories: multithreaded code and undefined behavior. Multithreading bugs often involve data races, I've seen code that crashed but ran fine once you put a print statement. It would be running fine in debugger, as well as with prints -- impossible to debug, have to put eyeballs to examine the code.
Undefined behavior is another common cause of bugs. In that case a debug build usually works fine but optimized build would crash. It's not fun debugging optimized build. Again, eyeballing the code I found "if(this)..." statements, which I immediately knew was a bug. The same person put code with side effects in destructor, which optimizer thrown away.
If you have to use debugger, memory tools, etc. too often that means you are not hiring competent programmers.

[ivanp_personal]

Yes, really, debugging optimized binaries generated by GCC is hell. Debugger is often useless. Microsoft C++ is far better in this sense. Someone have to enforce this in compilers like clang and gcc. That would be nice.

[rasitsimsek]

The gdb user interface and usage is horrible :)

[marcbotnope]

If you need to drop into the debugger you have done something wrong