No video :(

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

Подписаться 152 тыс.

Просмотров 16 тыс.

50% 1

cppcon.org/
---
Back to Basics: Debugging in Cpp - Greg Law - CppCon 2023
github.com/Cpp...
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.
---
Videos Filmed & Edited by Bash Films: www.BashFilms.com
RU-vid Channel Managed by Digital Medium Ltd: events.digital...
---
Registration for CppCon: cppcon.org/reg...
#cppcon #cppprogramming #cpp #debugging

Опубликовано:

27 авг 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 37

@CH4NNELZERO 4 месяца назад

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

@dolphin2954 9 месяцев назад

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.

@timhaines3877 9 месяцев назад

@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.

@donutsleader 7 месяцев назад

Debugging symbols are usually placed into separate segment in ELF and that segment is not marked to be loaded during dynamic linking. File size easily becomes tenfold though.

@simonfarre4907 7 месяцев назад

@@donutsleaderyeah. Dwarf lives in the .debug_FOO sections in the ELF binary. Loading the right segments is done in a literal instant.

@ivanp_personal 6 месяцев назад

I'd say I like far more the Microsoft approach - PDB files. Something like that must be default in GCC and clang too. Currently, to achieve that, I have to run few non-trivial commands over normal executable with debug info included.

@Yupppi 9 месяцев назад

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.

@simonfarre4907 7 месяцев назад

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.

@torstenknodt6866 7 месяцев назад

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.

@empireempire3545 8 месяцев назад

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

@heavymetalmixer91 8 месяцев назад

What about LLDB?

@simonfarre4907 7 месяцев назад

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.

@jacquesenboit6351 7 месяцев назад

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

@UvUtkarsh 8 месяцев назад

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

@jimcameron6803 2 месяца назад

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

@MalcolmParsons 7 месяцев назад

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

@rasitsimsek9400 5 месяцев назад

I dont using printf in C++.

@linyuzqlby2590 9 месяцев назад

🥰

@wjrasmussen666 9 месяцев назад

I feel like I spend too much time bugging!

@oisyn- 9 месяцев назад

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)

@SonicFan535 8 месяцев назад

Most people would just use a GUI wrapper for gdb, like the ones in Visual Studio Code or any proper IDE, which makes it work pretty much exactly like the debugger in the regular Windows version of VS.

@not_ever 8 месяцев назад

I had to use Visual Studio for the first time in three years yesterday and oh my god the pain. Is that the state of things in Windows? (I’m not joking this was my actual day and it ruined it). Linux has an array of debugging tools. Probably more than Windows. Also gdb can be used much more smoothly than this with a nice frontend gui or tui (not the one shown here) or in a text editor such as vscode or neovim. However some of us spend our time logging into headless servers/robots and knowing how to use gdb and other command line tools is important.

@9uiop 8 месяцев назад

@@not_ever What's your issue with it? Honestly I think the VS debugger is pretty decent. On Linux I'm using gdb/lldb with some frontends but it never works the way I would expect to.

@babgab 8 месяцев назад

@@not_ever VS blows away pretty much every other debugger I've ever used in terms of features and user interface. Speed and responsiveness I'll give you, I'm sure command line tools are pretty quick, but it's worth the pain for me.

@Alexander_Sannikov 8 месяцев назад

it's a very typical story how linux people keep shitting on visual studio because of their stockholm syndrome associated with gdb. it's best to just leave them be.

@unclechaelsneckvein 9 месяцев назад

And it's so sad

@USGrant21st 8 месяцев назад

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 6 месяцев назад

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.

@rasitsimsek9400 5 месяцев назад

The gdb user interface and usage is horrible :)

@haxhunyadi5582 8 месяцев назад

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.

@benstanley9788 8 месяцев назад

You can lead a horse to water...

@marcbotnope1728 9 месяцев назад

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

@USGrant21st 8 месяцев назад

... or somebody else has done something wrong. Every time I need to debug something it's because some incompetent programmers wrote horrible code.

@babgab 8 месяцев назад

I'd love to see how you'd work out that an OS bug or even hardware bug is responsible for your code crashing on x% of your users' machines without a debugger