I've been making my game, Project Space Squad 4086 for quite a while now and it has the basic game features down. The problem that has been presented to me is that I'm having alot of trouble finding the origin of a crash . All help is appreciated, I've been debugging it for the past week and tweaking the code along the way. I just can't figure out what is wrong with it. It gives an "access violation" when giving a value to an integer.
If you are interested in helping my pin-point this crash, I will send you the project to look at.
Thanks~ John DiSanti
P.S. So far everything has been going smooth, this by far is the hardest to solve crash I have encountered. I'm very sure that this problem can't be fixed without looking through the whole project. I'm actually kind of doubtful of anyone helping me but this is my last resort until I reprogram it.
________ Rolls-Royce Plc
Last edited by disanti on Tue Feb 22, 2011 8:06 am, edited 1 time in total.
I haven't been that proficient with the C++ debugger and am really used to debugging mainframe assembly.
But, by observation of problems that I have...
When I hit an error of something that seems like it should work, such as setting x = x + 1, and it blows up there. I back up one line or any other time a variable is accessed near x to see if I'm stomping all over x.
I've had quite a few instances of dashing 32 bit values into 8 bit holders.
Hmmm... I can't see what is going wrong, even when I look up a few lines from the crash. I don't know the first thing about assembler! Other than it looks like gibberish to me.
________ Honda cl100
Last edited by disanti on Tue Feb 22, 2011 8:06 am, edited 1 time in total.
Well, if you have an idea of where the crash is coming from, ALT+F10(Run to Cursor) is probably your best friend. Because, if you can make it to a particular piece of code without getting the Access Violation, than you know it's not that line. Also, while debugging, you might want to make your app windowed so your debugging session doesn't lock you out of your machine.
In any event, it seems to help me.
But, then again, I'm working under the assumption that you're in VC++ 6 (which is what I work in).
"Object-oriented programming is an exceptionally bad idea which could only have originated in California."
- E.W. Dijkstra
Yes, Visual C++ 6.0 and I'm debugging in windowed mode. I've never heard of the "run to cursor" feature. I'll have to google that.
________ Extreme q vaporizer
Last edited by disanti on Tue Feb 22, 2011 8:06 am, edited 1 time in total.
Basically what it does is break the debug once the session has executed all the code up to whereever the cursor happens to reside. Just place your cursor on the function causing you grief, ALT+F10, and the code will run up to the cursor and stop. You can then get all kinds of goodies, such as what data you're passing to your functions, if it's returning anything, if your variables are actually holding data or garbage, plus whatever you might need to know. It's good stuff.
"Object-oriented programming is an exceptionally bad idea which could only have originated in California."
- E.W. Dijkstra
I just don't get why it isn't working. I've tried deleting the array portion of the code from both the header file where the value is defined and this line of code and it works fine. I really need the array part though. What is going on?
definition of MAX_VALUES:
#define MAX_VALUES 24
where AI_VALUES is defined in the header:
int AI_VALUES [MAX_VALUES];
________ Zx14 vs hayabusa
Last edited by disanti on Tue Feb 22, 2011 8:06 am, edited 1 time in total.
The shortcut for "Run to Cursor" CTRL+F10, BTW. I end up doing it so often, I don't even know what keys I hit - just a trained monkey, that's all .
I'm assuming that you're in the midst of a for() loop or you're incrementing number_if_commands everytime you get an int from your xml reader. I'm curious what value number_if_commands is giving in your debug, esp. if the array is crashing your game. I'm working under the assumption that you're initializing it before stepping through the array (if not, that's your problem). What value is AI_VALUES[number_if_commands] returning? Also, are you putting quotes around the actual int value in the xml file? Not doing so WILL crash your game. Trust me on this - I've put this theory through the test already, and know it to be true.
Hope this helps.
"Object-oriented programming is an exceptionally bad idea which could only have originated in California."
- E.W. Dijkstra
Looks like number_if_commands is getting set to garbage. I'm assuming that number_if_commands is getting initialized. Is that an accurate assumption? If you're not initializing number_if_commands, that's the problem. Otherwise, go ahead and post the code.
For future reference, though, if you get a var equal to -858993459 (or some really large negative number) in your debug - and you haven't set it explicitly - chances are you haven't initialized the variable, and that's the value Windows has assigned the variable.
Hope this helps.
"Object-oriented programming is an exceptionally bad idea which could only have originated in California."
- E.W. Dijkstra
Thank you so much Luke923! That helped ALOT. My game is now working in perfect state now. Wahoo! I can continue work on it. I feel embarassed that I had so much trouble because of a stupid variable not being initialized!
________ Weed vaporizer
Last edited by disanti on Tue Feb 22, 2011 8:06 am, edited 1 time in total.
For future reference, though, if you get a var equal to -858993459 (or some really large negative number) in your debug - and you haven't set it explicitly - chances are you haven't initialized the variable, and that's the value Windows has assigned the variable.
This by far is the most common programming bug overlooked that leads to the maximum frustration. Some langugages always initialize their variables to 0 if not explicitly specified (VB/Java for example) and others do not (C/C++ for example). The strange thing is that in C/C++ if you declare the variable global, it automatically initializes the variable but there's no guarantee for local variables. And what makes this even worse is that different C/C++ compilers behave differently so gcc might follow one set of rules but cl, which is Visual C++ , follows another. Finally within the same compiler like cl, different versions behave differently when it comes to variable initialization. So version before cl 7.0 I think do not initialize their variables but 7.0 does. I could be wrong in some of these statements as they are generalizations....but I think the best thing to do is: - always initialize your variables no matter where you declare them
It happens, at least if you see that a variable is holding garbage you will recognise the problem and be able to fix it easily. I know the feeling of tearing your hair out over something that turns out to be simple, I'd be willing to bet quite a few others here would as well
. All help is appreciated, I've been debugging it for the past week and tweaking the code along the way. I just can't figure out what is wrong with it. It gives an "access violation" when giving a value to an integer. 
Other than it looks like gibberish to me.
.
Should I post the code?