For anyone who doesn’t know, in the older references, core meant memory, so when the core is dumped is actually writing the current state of memory into a file

Print debugging still is the most universal way of debugging. You can do it local, you can do it remote you can do it in embedded, you can do it in a high volume processing code that would be just time consuming to step through (or when you don't know exactly where the problem is and can't put conditional breakpoints). Core files can only help with memory problems (when your code crashes), but won't help when it doesn't crash, but just produces wrong resutls.

6:13 Fun fact, this is a mistake. As this array's length is 100, its maximum value is 99, so entering 100 will cause a crash anyway.

Core files and debuggers are indeed very useful. But honestly... the occasional debugging printf() is perfectly fine too. I've caught a lot of bugs that way without having to fire up a debugger.

After writing software for 40 years in many languages, from the highest to lowest levels, including patches to some of the software used in this video, here's what I've learned about debugging: 1. The best debugging technique is to just read the code. If the code is too complex to trace in your head, it probably needs to be rewritten anyway. 2. After that, nothing beats print style debugging. It's easy, simple, and works in almost any context. 3. Debuggers and profilers are nice luxuries to have sometimes, but are frequently not feasible.

Don't do "typedef unsigned int uint32_t". The size of an int is compiler dependant (although it usually is 32 bits). Include stdint.h if you *need* exact size integer types.

Debugging complex systems with time dependent interactions (user input, network connections, video game AI, user interfaces etc) are pretty much impossible with a debugger. The biggest problem here is that the debugger is extremely invasive in terms of time. You hit a break point and it literally freezes your entire application. This is a bit of an issue if you have code that interacts with real time things, which lets face it, is most of the difficult work in software engineering. I do use debuggers where I can and where it's the best tool for the matter at hand. But I am here objecting to the click-bait. Yes, please carry on using logging for debugging, as most debugging of complex systems really requires it.

minor correction: "ulimit -c unlimited" means allow a core file be created with unlimited size, not "the kernel is allowed to produce an unlimited amount of core files"

6:04 I think I noticed a small error in the if statement the last index of an array is always the size of the array minus one because arrays starts at 0 (except in LUA). So the maximum index of the array is 99, and not 100. if you select a box with 100 as ID, your program will segfault because index 100 is out of bounds. To fix that, you have to either replace the ">" sign to ">=" sign, or you can do if (i > 99) { ... }.

This man is the perfect programming KZfaqr for me. I’ve noticed lately at my uni in my courses that all the other students complain at an assignment/task that needs to be done in C (we’re in Operating Systems and we just wrote the first part of a shell where we had to create and implement the cd, pwd, and exit commands, now we’re going to exec the other commands as well as their arguments, and the whole class whined out loud when they were told that was the next assignment due next week. He also teased at the possibility of making us write our own memory allocator, which got even more audible rejection from the other students). However, I get excited at the thought of it. I love writing in C, I love the challenges it brings. My professor even pointed it out to me when I went to see him during his office hour to discuss getting an internship, how to go about it, what to prepare for, etc. that I seemed to really enjoy working at a low level close to the hardware. So, as a guy who seemingly loves writing low-level code, finding a programming KZfaqr whose channel name is literally “Low Level Learning” is the best thing that I’ve found on KZfaq this year so far.

Already using gdb on low level stuff, it’s ironic… thanks a lot man I’m really blessed by ur channel.

It would also be helpful to demonstrate how to write test cases and how best to separate into multiple modules. Also, you should check the number only once when read in from the user as well as stop using magic numbers. Might also want to demonstrate using `gdb` even if your program isn't crashing.

This is very basic debugging for crashes but the video title sounded like more. Print statements to deal with non fatal errors are still quite useful.

if i knew this in my first year where i've learned trees and graphs in C imagine all the seg faults thank you for this!

This is super helpful for beginners as well! Thanks a lot!!

It's a whole lot harder to use the core file when a released product crashes (no debug symbols). It is also much harder to use core files to track down crashes in multi-threaded programs, and impossible if the problem is caused by a deadlock elsewhere in the code.

I believe there’s still a bug. You can enter 100 and it still crashes as the index is 0-99 😉I find it remarkable that you remember all the the commands. I always have to look em up. Then again I hardly debug, my code is usually error free 😅 I actually just wrote my first ever C program on the Amiga to just open a window and draw random computed pixels. And not being able to run the binary on my Mac (Aros HDF required UAE version 4 which is not released on Mac yet). So I upload my cross compiled binary and awaited the first crash… but it worked, first time! Usually that’s a no go. Especially with a whole new windowing environment.

Great video Dave! Informative as always.

When I switched from python and C# to C, one of the problems I had was that there's no stack traces when something goes wrong. But this is actually even more useful than a stack trace. Amazing

That is useful if your program crashes, but not as useful if it just doesn't work as intended. I'm still 100% certain that print statements are more or less a quick and easy way to manage all sorts of bugs. Yes, debuggers can be useful, logs too especially if you have a huge project, but other than that it's actually fairly easy to just use print-statements when there are issues.

Woah this is cool! I wish I'd known about this when I still wrote in C back in uni. Great video!

For Linux C++ users, I really recommend compiling your project (-g -O0) against the backward-cpp library. You will have a nicely printed stack trace from your segfault. It is probably sufficient to understand where the bug comes from, else yes, use gdb and the core dump.

I like how you said we can look at the assembly instructions to debug this and resigned from doing so as soon as you saw them

I’m about to start using GDB in my codebase - thank you so much 👍🏻

Wow, this was a really well presented video. I never used this feature before, because I thought stuff like that would be overkill in most scenarios. But the way you showcased it made it seem pretty handy, while note being as complicated as I imagined. I will definitely try this out next time I code something.

I've been patiently waiting till I finally stumbled across someone who explains these concepts as well as you. Thank you so much sir! I am so excited to learn with you :)

If you're using systemd, it'll hold on to some amount of cores, and coredumpctl will allow you to start a debugging session with any of those cores.

Holy shit, this is so useful! I cannot tell you the number of hours I’ve spent tracking down sigsegvs! I didn’t even know the (core dumped) meant anything 😂

Really nice ! This is why I want to learn assembly it's really helpful in all cases

Good video , i just saw a video from Dave Plummer (ex Microsoft software engineer) and i learned to use the f_s functions all the other F functions are not safe, can bus buffer overflow , the new way so use prtinf_s, the video of Dave is called Stupid C tricks , i saw it and he's right , has to do witn functions not taken in account buffer lengts, and not checking them , not adding null remintator and so on, there are new functions and they have in common that they are named as the original functions but added with _s , these are safe functions can not induce a buffer overflow, good explanation also from Dave.

Half a semester of debugging seg faults, why did I not look this up earlier? THE PAIN!

Also, don't use scanf. Use the secure variants, and try to reject input as soon as it is parsed, not later on as per his example.

I haven't tried a core dump, but as soon as he said "let's look at the assembly" my eyes glazed over. I'll stick with my print statements and debugger combo. I've never had to abandon my code and start over; that sounds nightmarish

Won't your program still crash for i = 100?

Another way to avoid the print statements that get confusing is to use asserts. Forcibly fail when the conditions you're desiring aren't met, or the conditions you're seeing are. It's printf debugging but only one message prints, and it means it's much more comprehensible when something does go wrong. It doesn't always substitute a debugger, but they're good practice anyway, so it's a good idea to use them regardless of if you're debugging or not

Not always debugging used to fix crashes and sometimes gdb can't show proper backtraces due to absence of debug symbols or code version of the build. Also real-time tight programs will not let to stop themselves so prints is the only choice in many situations.

What is the point of looking at the assembly instructions and register states? To me, it looked like you gained nothing from looking at them.

Nice syntax, I really like when someone takes care of readability and looks at the same time!

Thank you so much... it's really hard to find good content about gdb.

Nice explanation of debugging. Thanks!

For Windows fellows, the equivelant is a .dmp file that is either next to the program or some crashes folder, and Visual Studio would be used to open it

KZfaq programmers: COME OUT WITH YOUR PRINT STATEMENTS UP Me: You'll never take my print statements, copper! NEVER!

For this simple example, printing i would have found the bug sooner. However, I do see that this can be useful for truly complex bugs, but not necessarily better than print statements.

Excellent tutorial. Although not a solution for every bug, it's still a great way to debug C memory-related issues.

I didn't know you can actually configure core like that. This is pretty useful.

I never knew what "core dumped" meant, this makes so much more sense now! Thank you :)

You also can use the flag -fsanitize=address -g flag for these seg fault , buffer overflow, etc...

recently i've been using assert alot more, and that's been much better than print statements for some usecases

I used printf debugging over the weekend, of course, it was in a M1 kext, so no core to get, and apple kext lldb is very poor on M1, and panic dump sending is broken. It's not always the wrong thing to do, if you have no other choice :) But when it works, it's a beautiful thing!

Something that print debugging allows, but no traditional debugger (to my knowledge) supports, is seeing how certain values in your program evolve over time, like in any kind of loop. Seeing the change over time allows me to figure out a potential pattern, and from there derive the issue way faster than most other traditional debugging techniques. This becomes even more valuable in a language like Rust which has really rich formatting support and prevents most types of crashes from the get go, so the majority of bugs I need to fix are logic bugs, where finding patterns is often pretty fast.

I usually add a couple of debugging options to programs, even shell scripts, which enable either some basic logging or that plus an overkill data dump. That way I can trace behavior without code changes. A "debugger" isn't always viable for whatever reason.

Super useful. Thank you very much :)

Cool trick - I think I used this once a long time ago. Typically I just hit run on my IDE and it stops the debugger automatically on the line where the crash happens. Takes about 5 seconds to fix a bug like this.

This is a great video thanks. I generally use ifdef debug printf() style to isolate an offending function and create a new entry point and test that function to destruction. The only debugging tool I've been using is valgrind --leak-check=full. This is great. Cheers mate.

Excuse me, but I add a bunch of prints to figure out what's wrong and eventually I DO crack the code. Works every time.

Hi, wanna know why do you have two naming patterns for your methods? read_int() and EditBox(), for example. Is there any technical reason for that?

Ah, Seven reference.

Short question: Can the parent process define a special core pattern for its child process or must it always be system-wide?

Holy mother of valgrind, I was just struggling with debugging a program when you dropped this video...now my program works. Thanks :)

I'll stay loyal to my prints, thank you

Or you can gcc -fsanitize=address to see where the segmentation dump core occurred, we use this method alot to understand where the pointer has failed. If not this, valgrind is the second choice of command to understand memory leaks.

Thanks for this!

this is so helpful, thanks!

3:07 I was going to do what you did there to core_pattern but I found that apport already had a pattern in there. I'm concerned that if I did what you did, then I'd be messing with apport and that sound improper. Is there way to get the core dump for your programs where you can find it while leaving system error handling unaltered?

Still allowing index 100 and that's bad too :P

Really cool and useful, thanks for sharing!

Starting in debug mode often takes 2-3 times longer so a log is usually more efficient. I only reach for the debugger when logs fail or are too cumbersome.

Really it goes to the core!

What's really fun is when your program cores with the -o option, but doesn't when you specify -g!

Wow today i learned why some say tack instead of dash. Interesting. Still makes my eye twitch every time I hear it.

Thanks. That was a very useful demonstration.

Although I agree with the concepts in relation to crashing programs ...the use of printf or console debugging is still the best answer to figure out complex bugs like drag and drop and other scenarios where you do NOT want to stop execution but observe the flow. Also the best thing I saw done for a memory corruption problem was s senior engineer wrote a memory manager that would allocate restricted blocks around every block requested...so while running BAM it would trigger the debugger right when the memory was stepped on.

I'm confused at what looking at the registers gave us - you opened it and said what we were trying to do but didn't say anything about why that was bad or how we could use that information. Seems you could have just looked at the program .c file and gotten the information without looking at the assembly

Useful. Nice introspective.

What I'm trying to understand here is how the values in rax and rdx gave away the nature of the issue.

The funniest experience of learning c is starting using print statements for debugging. Learning about debuggers and perror. End up programming drivers going back to using printk to print statements in order to debug :p

You probably meant >= 100, if you will type 100 as a box id you will have the same SEGFAULT

ITS REALLY WORKED LOL THANK YOU DUDE

The reason I do print debugging is rarely to debug crashes, it's to understand the flow of logic.

You are a life saver, thank you.

Awesome, great video!

I will be using print debugging and you cant stop me. It is the best and only way to debug.

2:01 yeah, hacking string with segment fault then u core dump and other things that i forgot

Beside using core dump files is a useful and really powerful debugging technique. Using some Logging or print statements stay still useful too.

This is great if you’re writing for a PC environment. Can’t use core files on embedded, a debugger and a robust logging system is the best to debug quickly. Also 99.99% opening up the assembly to see what’s going on is just to take more time than looking at the source

i had a rendering program and i wanted to debug one part of a function which is called thrice for every pixel, i was confused why printf was making sdl not render the frames even though the printf was working, took me over an hour to realise i wrote code that was so slow i didnt even notice it was running

An address sanitizer compile with -g would help lots as well

Ive spent 30 years working in software development and never had an issue with print debugging. In fact its got me out of many holes. And sometimes its the only option if running the code on the server is the only option and you aren't able to run a debugger or similar on the server.

Hint : use sudo -i instead of sudo su. Same experience except all commands you’ll use can be logged properly as a sudo use.

Can you do a video on how to add assertions and performing a core dump once they get hit on a remote target? :))

5:21, the mov instruction actually does the opposite of what you said, because it's in AT&T syntax.

Good stuff, man.

so much to replicate something visual studio has out of the box lol. i didnt even realize fully that i kept running my VS program in debug mode all the time

5:18 in gdb is used AT&T assembly notation ; INSTRUCTION ORIGIN, DESTINATION ; and not in INTEL (more used) assembly notation (aka. INST DEST, ORIG)

I needed this yesterday!

thanks! super useful.

I've noticed that you use Visual Studio Code for C. I'd like to have it again but after many problems, I had to return to Visual Studio. If you don't mind: do you have some video or blog that explains how to set Visual Studio Code for C in windows 10 ? It consumes much less hard drive space among other things. Thanks

Very helpful video. I think the core dump is for the linux machine you are running. Can we do the same for target microcontrollers. If yes, can you tell how to do it? Beginner here.

Yes, but does it help if you forgot about the memory alignment requirements of SIMD instructions that end up giving you “access violation reading location 0xFFFFFFFFFFFFFFFF”? My compiler assumed it was aligned and generated aligned load instructions for an unaligned field. It clearly assumed wrong.

03:16 Security hint: Always use "su -" when changing to root to avoid keeping a compromised environment.