Back to Basics: Debugging in C++ - Mike Shah - CppCon 2022
Вставка
- Опубліковано 18 вер 2024
- cppcon.org/
---
Back to Basics: Debugging in C++ - Mike Shah - CppCon 2022
github.com/Cpp...
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.
__
Videos Filmed & Edited by Bash Films: www.BashFilms.com
UA-cam Channel Managed by Digital Medium Ltd events.digital...
#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!
Cheers! If you have a lot of output you can redirect stdout to a different terminal window as well :)
@@MikeShah thanks for this tip I didn't know about this one
The talk I had I wish I had gotten during my first software engineering job after college.
Cheers!
Mike Shah awesomeness again 🎉
Cheers!
Great talk!
Cheers! Thank you for the kind words!
Mike Shah was an MVP professor when I was at Northeastern -- can't wait to dive into th is talk!
Cheers, thank you for the kind words Edward :)
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.
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.
Back to Basics indeed
Very useful, Got to learn a lot more about gdb,well explained
Pleased to hear that the presentation was helpful.
Cheers!
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.
Great story on adventures in debugging! The implicit initialization to zero in debug mode is a good catch! I've also heard a couple interesting stories with printf improving performance because it changed the code layout just enough to give a performance boost as long as nothing else changed 🤣
Would it be more convinience to use gdb on the terminal or debuggin with the help of some IDE like VSC?
Some folks like IDE's, some like terminal. Terminal sometimes more flexible with scripting -- i.e. you get the full tool. IDE's have some nice features too though, sometimes tools literally let you drag the instruction pointer back in time which is cool :)
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.
Highly distributed environments or networked environments that are data driven and asynchronous problem do need different tooling :)
@@MikeShah Sadly yeah. Would be nice if there were some easy tools... or if my company at least provided anything.
Really informative
Glad it was helpful!
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.
Very cool! Agree, next round would show rr :)
actually if you just press enter it repeats the last command, no need to keep typing next next next etc
Correct :) Can also do 'next 5' or something. Showing the commands a few times until they sink in :p
Nice talk!
Cheers!
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.
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?
Found them!
www.mshah.io/conf/22/CPPCON2022_BacktoBasicsDebugging.pdf
Cheers, slides are on my website!
The next gen debugger will some kind of GPT-assisted.
is the topic DEBUG funny to you ?
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.
Yup, I've been there. At least with a debugger and taking notes, hopefully some progress can be made. Things like 'ptype' very useful when working with lots of structs.
How come a talk on debugging does not mention Valgrind and sanitizers?
Because it didn't even have time for all of the basics?
Would have loved to talk about that -- but static and dynamic analysis I think is a separate talk for beginners :)
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%
I think the cost estimates come from opportunity cost losses and delays in products :) It's true we cannot allocate an engineer for more than 100% of their time though :)
@@MikeShah I see. I would say the bugs are what add opportunity cost losses, not debugging, but maybe I'm splitting hairs.
@@Dziaji Opportunity cost is about return on investment of the resources, so programmer time debugging that could have been used for fresh development. The cause is the bug from a managment view, but on the accounting/econ side the cause is just a part of sunk costs, so not relevent to the current state and choice to invest more.
When I saw the difference in time and cost on the slide I just assumed that they were using their more highly paid programmers to debug.
"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!
Preference to debug using an IDE? Class of bug and experience level likely factor into where to start -- I think learning command line is important. What are your favorite debugging tools?