BUGSMASHERS! Episode 07

Transcript — every row opens the video at that moment

1. 00:00:00

   Hey everyone, welcome back to another episode of Bug Smashers. Let's get smashing. Bug Smashers. Hey everyone, we're here in Well, we didn't even get to the level. Um, we're getting this fun assert right here where we are accessing an array out of range and causing all sorts of fun memory corruption. Uh this bad boy here was actually cause of some of our internal crashes that just so happened to corrupt any data it desired. So if we break inside the code break, we'll take a look at what's happening. All right, so we're here in this little chunk of animation database for Mannequin. And mannequin is our

2. 00:00:49

   little state machine we use for controlling animations on the vehicles and on the players. And unfortunately, we're getting a fun issue right here. So, here's our little container. And we are accessing index one. But if we look up here, our max index is one. And because um C++ is zerobased indexing, so if you want to start off at the first um index, you have to actually start off at zero, not one. So one is probably supposed to be the second value. However, our max size is one. So we end up going out of bounds and writing into whatever memory is after that array. And let's take a look why.

3. 00:01:38

   So we have this little block here that's parsing a XML node. It found three little entries. And it is assumed that oh joy. It is assumed that at least some of these entries are going to be um I guess an animation node. So as we're going through these uh little um XML nodes, anytime it finds an animation, it bumps the index and then it writes to it into the blend, which gets fun. So let's take a look at our node that's causing the trouble and it's this bad boy right here. So, the way that this mannequin is set up, it's expecting this or you have a blend and an animation. Why it

4. 00:02:30

   was set up this way, you'd have to ask the good old folks at Krytek, but we will figure out why this happened. Um, so we'll put this back here. So, we have two blends and an animation. Well, when I looked at Perforce earlier, the reason why this happened was because a fun XML merge. Um, you're supposed to use a tool when doing this, not raw editing. And if you raw edit, sometimes these things get bad and then the parser goes nuts. So, let's first remove this blend from here. So, we only have one. And then we'll stop the game. We'll add in some code so in case we ever get to this state again, we don't

5. 00:03:20

   want to me corrupt the memory. We want to say, "Hey, we found all the animation nodes that we're ever going to find. Let's stop going through this loop because if someone decides to do two blends, whoop-dedoo, it's an error, but at least won't crash the game. it will parse this blend, replace the prams with this one, and then find the animation and stick it in there. And then if we have this case, it will find the blend, then the animation, and this will never get parsed because we only had one animation. All right. And if we happen to have two blends instead of an animation, um, it should be fine because it just won't load the animation. and you just won't see anything, which is you a quick

6. 00:04:09

   visual thing you'll see right away. All right, so once we hit our maximum clip number, we are going to break and stop looping because we found everything. And we're going to do the same thing down here and break Woo! Easy peasy. Now, let's build that bad boy. All right, we built Oh, I'm building that bad boy. I'm built it. You could edit that. Oh, it right out. What? What? What? Okay. What? All right. So, as

7. 00:05:01

   we're loading this up, uh, we'll tell you guys about the little fun, um, thing that's happening in more description. So, we have this array that we're sizing up to be, let's just say, one block. And if we go over that block and we start writing to memory, it can be anything. Um, a good example of this is pretend we're at a shooting range and we set up one wall barrier. And when we shoot the gun, it's supposed to stop there. But if we shoot the gun and it goes past it, who knows what will happen. Maybe we'll hit someone on the other side. Maybe we'll hit another barrier. Or maybe it will zing and do what Miss Busters did where it ricocheted and goes inside of a house. Basically, bad things happen. Don't want to write over random memory.

8. 00:05:51

   You want to make sure that you are within the ray of bounds otherwise bad things happen. What? Okay. All right. As you can see, we didn't get that um array index issue. We got something else, which is another bug. But we're no longer getting those array index out of error bounds. So we're no longer writing to random memory and corrupting who knows what. And the level should continue after a few of these fun [Music]

9. 00:06:40

   asserts. Those asserts luckily are just little warnings and will cause faults like the index one. And there we have it. We are finally in our test level and we haven't corrupted any memory. Woohoo. All right. So, as you can see, we had a fun little bug with uh some memory corruption there. And mannequin. Uh mannequin. Mannequin. Mannequin. Mannequin has been a long and gone fun issue. Dan loves mannequin. Right Dan? Yep. Yeah, he loves it. That's why we call him Danakin. All right. So, we had some fun little there. Easy peasy memory corruption that we fixed. Luckily, we got an assert, so we were able to track it down. It actually took a while to find. Um, but

10. 00:07:29

    got it done. Whoa. All right, let's look at some questions. Uh, let's see. Where'd he go? We have Sparky. He wants to know, "How do you find specifically where code is broken? you have a physics issue with a character not jumping. Do you know right where in the thousands of lines of code where it's located? Do you search for it somehow? Uh, basically if something breaks, you look for characteristic behavior. Is it something related to the players? Is it something related to the vehicle? Is it something related to not, you know, an item? And when you have those sections, you can start jumping to those specific code blocks. And it also helps that you go on Skype and yell at the people who know that particular

11. 00:08:18

    section of the code. Once you have a general area, you start looking for um anything significant in the code that sticks out like um for that physics issue last week where um when you jumped it would actually move the ship around, that's obviously going to be somewhere in the physics. And since it's the player, it's going to be with the player physics. So, we I dived into the player physics, looked around a bit, and saw this specific flag that's not supposed to move um objects around when it's set. So, I went to the vehicle code and like, oh, there's the vehicle is setting this flag, but it's still moving. So, then I went back to the player physics and was like, okay, this is getting set, but where is it falting? So then you look into the other physics code and see

12. 00:09:08

    where the impulse gets happen. You just go back and forth tracing and tracing and tracing and tracing. There's sometimes you're lucky and you know all right this behavior it's going to be here. This behavior is going to be there. But sometimes you kind of have to just jump in put break points put in messages and try to track it down. The art of debugging is a really, really, really complicated and fun thing to do. Um, I'll send Tom some links about some helpful resources so you guys can take a look at that. Yes, I'll send you the links this time, Tom. So, this next question is more of a general question that I've seen a lot of people ask, and it's mostly suggestions on what people can do to get into the field or to get a um you

13. 00:10:01

    know, an engineering position. They want to know what they can do to improve themselves. I made a list here and I'll read them off. Quick steps. Every day try to code something small. Um next step is start with small projects. Lead yourself up. You know get bigger over time and practice debugging. You know set some break points, set some messages. Try to find solutions to problems you've never faced. Um if you have something that you have no idea how to complete or something, ask for help, but tell people how what you have done to get that far. and maybe try, you know, stepping away from it, coming back and then looking at it again from another perspective. And then finally, join other projects. You know,

14. 00:10:49

    if you're right out of school, join a small indie project because you'll face problems you've never faced before. And being able to solve those things just advances advances and advances your programming knowledge. But basically, you want to practice coding every day. Start with small projects and then slowly get bigger. Don't start with big projects first. You'll get overly frustrated because you don't know how to design systems. And I've seen many people just go a crap out of it. Yeah. I don't know how to end this one. I'm going to leave that to Tom edit it. You're welcome, Tom. You're welcome.