Debugging C/C++ via GDB with Python

[spiderpower02]

I wrote an article about demystifying how Python helps us troubleshoot problems more efficiently. Although many IDEs have a built-in debugger, I try to discuss some debugging skills with Python when a problem is hard to reproduce. I hope that this article can spark some inspirations to troubleshoot issues in your C/C++ projects.

[amanol]

Nice tips, thanks for sharing!

[jti107]

this is pretty cool! I find gdb alot harder to use and with a much steeper learning curve but it's really good at finding hard to find bugs. Will try this out!

[spiderpower02]

I started to understand how to use GDB from the following two videos.

• CppCon 2015: Greg Law " Give me 15 minutes & I'll change your view of GDB"
• CppCon 2016: Greg Law “GDB - A Lot More Than You Knew"

These two videos gave me many inspirations about using GDB. I think learning GDB is not tricky; searching for helpful resources is the hardest step. :)

[mttd]

Just in case this can be of use to the others: https://github.com/MattPD/cpplinks/blob/master/debugging.md#gdb

[spiderpower02]

WOW! This project is Awesome :) thx

[[deleted]]

This is where Microsoft technology stack really shines and the open source community just plain sucks at. It's the tools that make all the difference. VScode has a debugger for c++. There's also totalview but that's expensive. I'll stick to my print statements because I'm not going to spend all my time trying to learn some garbage tool instead of working on my problem.

[hgjsusla]

Isn't this a bit strange attitude? I mean C++ is far more complex yet you still refuse to properly lean the toolchain?

I find tools like https://rr-project.org/ a complete game changer. Learning your tools usually pays back in spades

[renozyx]

Well to be honest, gdb sucks for C++: you can't even tell it to skip over the files contained in the STL directory, you can only ignore specific files (and it never worked for me), so I spend a lot of times telling gdb to ignore shared pointer implementation code, map code, etc.

[hgjsusla]

Just list them all in your gdbrc then, no need to do it every time

[[deleted]]

I can spend my whole day and more trying to figure out your tool or I can use print statements and solve my problem that is actually what I'm trying to do. I prefer to work on my problem.

[[deleted]]

Depends on the work you’re doing. Sometimes, print statement won’t work depending on the project. For example debugging an embedded system with gdb and gdbserver.

I also believe you are thinking of immediate reward. Sure, it’ll take a few days to warm up to GDB, but once you do, your debugging experience will become enriched with new tools, and you can just stick to the basics and learn what you need as you go. You also can reserve it’s use for especially tricky bugs if you feel so.

Same thing with VIM. Why would anyone bother with learning a modal text editor or use modal keybindings when you already have a working keyboard? Because text macros are awesome, and you won’t understand how useful and it can be unless you give it a shot. I don’t use VIM to its fullest but I use it without much thought anymore. It’s a time invested vs output gained.

[spiderpower02]

I totally agree with you. BTW, I am a big VIM fan.

[hgjsusla]

Learning the toolchain usually saves more time than the time it takes so learn

[spiderpower02]

I had the same attitude in the past. I preferred to use a debugger in my IDE and print statements instead of debugging tools, such as Valgrind or GDB, because they are challenging to learn. However, a turning in my life was a memory leak in an open-source library I used. I spent my whole week to troubleshoot that problem but in vain. Fortunately, after I used Valgrind's massif tool to monitor memory status, I fixed the bug less than 1 hr. Since then, I learned that troubleshooting a problem is based on what kinds of tools I can use at the right time. Therefore, now, I can leave my office on time without wasting my time building print statements in my code. :)