Hello Guest, please login or register.
Did you miss your activation email?
Login with username, password and session length.

Pages: [1]   Go Down

Author Topic: Debugging Guidelines  (Read 1625 times)

0 Members and 1 Guest are viewing this topic.
Debugging Guidelines
« on: August 28, 2006, 04:05:09 am »
  • The Broken King
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1259
I'm writing this topic to help the many programmers out there. Now, in general, these techniques will probably be most effective with C++. There are reasons for this:

1) C++ has a huge user base, so there is a lot of information about it.
2) I use C++.
3) The C++ questions asked around here are usually painfully simple to solve.

As you program, you expect less and less to have someone hold your hand while you program. After all, why would you want people to tell you how to program? You want to be able to program whatever you want, and say, "look at what I made!" There's a certain pride to having your code be completely self done.

Yet it seems that as soon as you hit a snag, you suddenly don't know what to do. You look at your code, and as far as you know, it should work properly. Yet it's not - you're getting an error, or it's just not working.

Computers are not wrong. Let's just put it that way - no matter how frusturating your code is, no matter how long you stare at it and say, "This should work! Why doesn't it!", you're computer is right. No matter *how* dumb the error is.

If the first thing you do when you have an error is ask someone else for help, including a forum, you may not learn all you need to know. Now, I'm not saying don't use forums - forums are invaluable resources for fixing problems, and a lot of problems are solved on forums. But there are better ways to find an answer.

Step 1: Read the error.

This is pretty self explanatory, but it's something that definitely needs to be covered. Read the error. And if you don't nkow what it means, figure it out. In most cases, the error will tell you what exactly went wrong with your program. This is the first step to telling you why your program isn't working.

Step 2: Try changing things

Well, if you have an error, why not try doing it a differnet way? There's usually multiple ways you can go about doing any one thing, and if one way isn't working, why not try another one?

Step 3: Google the error.

Okay, so you got an error, you couldn't figure it out, or you figured otu what it meant, but you don't know how to fix it. So you google it. This isn't always a solution, but (especially with a program like C++ that has tons of users), chances are, you're not the first person to have this problem. Someone else has probably encountered it and solved it before, and there is often documentation on cases such as this. You can often find tons of solutions online.

Step 4: Find existing code

find similar code that does the same thing yours does, and compare yours to that code as closely as possible. IF they do something differently, look at why, and try to figure out if it's relevant to your error.

Step 5: Ask for help

Final step, and provide a list of the things you have tried already.


Well, the above steps work relatively well, but sometimes, you don't kow what the problem is. This happens increasingly as you start workign with more complicated subsystems, and stuff like dlls/direct x/etc. Your program compiles, but your problem is at runtime. This is when debugging skills really pay.

First of all, save a lot of backups, in case you screw anything up, so you don't lose all your work.
Second of all, try the first four of the above steps.

Now, I'm going to take a case study of an error I had. I'm writing a 3D engine, using direct x, with seperate dlls for input managers/settings managers/etc., and for the most part, it worked. Soemtimes, however, a single line of code would make it stop working. However, both logically, and according to the rules of programming, that line of programming should work.

There was another strange thing. I would put a break point in at the line before the line that caused the program to crash, but the program would never hit that breakpoint while debugging. Id' run the program, and before it hit the first line of code, it would say, "The application failed to initialise because MSVCR80D.dll could not be found."

I found the dll in the folder it was supposed to be in, and copied it into the folder with my solution, but it just created another error about trying to link to it incrementally [or something like that], and after researching that, I gave up and deleted the copy of the dll. I tried changing the code that caused the error, but it didn't stop working. Eventually, I went to a backup copy and just started working forward again.

When I reached about the same point in my program, I got the error again, and for a week, I coudl not figure out the error, before I finally started over from scratch. (this was for a huge homework assignment, too, btw, so that week was costly, and so was starting over).

During this week, I upgraded from Visual Studio Express to Team Edition, because most of the online resources claimed that the error was a bug in Express. (actually, most claimed it was an error in the beta version of express, and mine was a final verison). I still had the error, however.

I wondered if it was my computer, and ended up even reformatting - but to no avail.

For two days, I worked on my project non stop, not quite catching up to where i was before. Yet, I ran into that error again. I found that by going into a backup, and copying all my existing code, the error went away - which stumped me. It was not my code that was causing the error, it was something happening in my solution. How could I fix this?

This happened again, only this time, backtracking and copy/pasting didn't fix the problem. I figured out what line of code was causing the problem, but not why, and it was code I needed, and that I couldn't figure out how to do otherwise.

After searching on google for a couple days, and trying my best to get rid of the error (and ignoring it to work on code that I couldn't test), I realised that a forum topic I had found had pages beyond the first. On the third page, I found out that the issue had to do with my manifest files. In fact, I tried about 10 different things before I found one that worked.


Moral of that story? Keep on trying, use the internet, save backups, and be sure to know your compliers options, becuase if its not working, you may need to change those!


Here's another case study:

In direct x, there's a function that takes a 256 lenght array of BYTE's in order to read your keyboard data. I used this function, but it wasn't working. After reading about it in the documentation, I put in some break points and ran through the code, stepping into every function I could, trying to figure out what exactly was breaking. (It took me a while to realise that this function was where it was breaking, as it wasn't until later on in the code that the effects of this function not working occurred). I put in some debugging statements that messaged when each possible fail method occurred. I figured out that the error was that I was handing in invalid parameters.

Well, the function took the size of a void*, and the void*. because I was doing keyboard input, the void* was a 256 length array BYTE. The code that I had learned off of declared the BYTE as

BYTE diks[256];

I declared mine as

BYTE * res;
res = new BYTE[256];

I did it this way because originally, I had passed it into a function, which just needed a BYTE pointer, and which made it into the array for me. However, it turned out that this was a problem. As soon as I changed my code to:

BYTE res[256];

it worked.

The lesson of this story? 1) check existing code, 2) use breakpoints and your compilers debug tools, 3) change things

Hope these case studies helped, I know that this could be better written, but I got distracted halfway though.

[mods...I put this here because I'm hoping that people who come her looking for help will see it. I don't thik it belongs in tutorials/engines and would appreciate it if it stayed here, but if not, meh, it's not my call.]
Logged
  • Broken Kings [Temp Site]

gm112

Re: Debugging Guidelines
« Reply #1 on: August 28, 2006, 04:07:42 am »
Sticky this please.
Logged
Re: Debugging Guidelines
« Reply #2 on: December 14, 2006, 04:50:17 am »
  • The Broken King
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1259
Logged
  • Broken Kings [Temp Site]
Pages: [1]   Go Up

 


Contact Us | Legal | Advertise Here
2013 © ZFGC, All Rights Reserved



Page created in 0.194 seconds with 43 queries.