[Edited by - ProcedureX on January 21, 2005 12:34:25 AM]
🔒 Locked
Visual Studio 6 - Debug Issue.... (Solved, stack-overflow)
Advertisement
Original Post
Ok, I removed the other thread, so that I could focus the thread on just this one question. Project Background - Visual C++ 6 - Procedural-C (Strict) - No threads, unions. What could cause this? (Look closely at the debug values shown via the debugger. Both those values should be equal, yet one of them is 0.)
[Edited by - ProcedureX on January 21, 2005 12:34:25 AM]
[Edited by - ProcedureX on January 21, 2005 12:34:25 AM]
amawgwd!
Impossible that no one can explain this.
@avianRR
I'm gonna try using a different compiler, and see if I can get an insider on whats cuasing this phenomenon.
Edit: How do I get the Visual Studio 2003 Toolkit compiler to work with Visual Studio 6? (Unreferneced blah blah _CheckESP?!)
Impossible that no one can explain this.
@avianRR
I'm gonna try using a different compiler, and see if I can get an insider on whats cuasing this phenomenon.
Edit: How do I get the Visual Studio 2003 Toolkit compiler to work with Visual Studio 6? (Unreferneced blah blah _CheckESP?!)
Quote:
Original post by Zanthos
My only suggest from what I can see is that it could be an overflow problem of some sort... possibly.
Between 5 lines of code? All of which are matching datatypes.
I've followed the debugger through the code, there doesn't appear to be anything wrong with my code.
It doesn't make any sence. All the values are perfectly fine untill it reaches that line!
In addition, after running it, I need run some differnet programs, or restart or something cause the values stay screwed up.... [mad]
It doesn't make any sence. All the values are perfectly fine untill it reaches that line!
In addition, after running it, I need run some differnet programs, or restart or something cause the values stay screwed up.... [mad]
Intel Compiler 8.1
Tested it on my project. It ran into either the same or similar problems. If this is a buffer-overflow problem, its by far more complex than any I had ever encountered before. [looksaround]
Tested it on my project. It ran into either the same or similar problems. If this is a buffer-overflow problem, its by far more complex than any I had ever encountered before. [looksaround]
Bump: someone must be able to explain this.. [depressed]
what's the value of intHook? if it's bigger than the size of the arrHooks array you could run into problems.
Also, what's the value of arrObjects[l].intX after each line of code? does it change when you step onto the current line shown?
seeing the structures/classes would be helpful as well. As would the code that creates the arrays.
Also, what's the value of arrObjects[l].intX after each line of code? does it change when you step onto the current line shown?
seeing the structures/classes would be helpful as well. As would the code that creates the arrays.
Quote:
Original post by Gav
what's the value of intHook? if it's bigger than the size of the arrHooks array you could run into problems.
0
Quote:
Original post by Gav
Also, what's the value of arrObjects[l].intX after each line of code? does it change when you step onto the current line shown?
It starts at 0, than upon reaching .intX it becomes 32768. It appears to remain constant.
Quote:
Original post by Gav
seeing the structures/classes would be helpful as well. As would the code that creates the arrays.
struct strHook
struct strHook{ /* Header Information */ char bytUsed; char bytInGame; unsigned short intObject; /* Character Information */ char chrName[15]; char chrPassword[15]; char bytType; unsigned short intTileX; unsigned short intTileY; unsigned short intHealth; unsigned short intMana; unsigned int intLevel; unsigned int intSword; unsigned int intShield; unsigned int intMagic; char chrInventory[43];};struct strObject
struct strObject{ unsigned char bytIdentity; unsigned short intX; unsigned short intY; unsigned short intGridX; unsigned short intGridY; unsigned char bytPrimaryShootDelay; unsigned char bytSecondaryShootDelay; unsigned char bytAttack; unsigned short intHealth; unsigned short intMana; unsigned char bytGraphic; unsigned char bytSpeed; unsigned char bytAnimationFrame; unsigned char bytLastAnimationFrame; unsigned char bytFacing; unsigned char bytUsed; unsigned char bytLevel; short intValue; unsigned short intDuration; unsigned char chrMessage[80];};Globals (Not good programming style, I know)
unsigned char arrMap[250000];struct strObject arrObjects[250000];struct strHook arrHooks[10000];
Bump! [razz]
Edit: I HAVE NO IDEA HOW TO FIX THIS?!!! [bawling] [depressed] [bawling]
[Edited by - ProcedureX on January 20, 2005 10:35:11 PM]
Edit: I HAVE NO IDEA HOW TO FIX THIS?!!! [bawling] [depressed] [bawling]
[Edited by - ProcedureX on January 20, 2005 10:35:11 PM]
Here is one suggestion - make
into
If this does not work I have another suggestion typed.
- Drew
unsigned short intHookinto
unsigned short int intHookIf this does not work I have another suggestion typed.
- Drew
Quote:
Original post by Anonymous Poster
Is it possible that you are running out of stack space having
unsigned char arrMap[250000];
struct strObject arrObjects[250000];
struct strHook arrHooks[10000];
declared on the stack, try creating them with new so they are on the heap
That was going to be my next post! [tears] Anyways I agree with AP.
int main(int argc, char *argv[]){ printf( "arrObjects Memory: %i\n", sizeof(arrObjects) ); printf( "arrMap Memory: %i\n", sizeof(arrMap) ); printf( "arrHooks Memory: %i\n", sizeof(arrHooks) ); printf("Total Memory: %i", sizeof(arrObjects)+ sizeof(arrMap)+sizeof(arrHooks)); system("PAUSE"); return EXIT_SUCCESS;}The results are:
arrObjects Memory: 27,500,000arrMap Memory: 250,000arrHooks Memory: 1,040,000Total Memory: 28,790,000(I added in the commas)
- Drew
Yup, that did it.
I spent four days debugging my project:
-rewriting sections of coding
-implementing my own version of the assert
-using the GCC compiler
-using the Intel compiler
-considering using std::strings (What a horrible feeling for a C developer [razz])
-googling any recorded historic issues with memset & memcpy in C
All to discover it was a simple stack-overflow!
So now I have another thing to worry about. When your debugger goes nutts (and I mean litteraly nuts), it could be more than a buffer overflow!111
I honestly didn't believe this problem would get solved...
Thanks AP & Drew. [smile]
ratings++;
I spent four days debugging my project:
-rewriting sections of coding
-implementing my own version of the assert
-using the GCC compiler
-using the Intel compiler
-considering using std::strings (What a horrible feeling for a C developer [razz])
-googling any recorded historic issues with memset & memcpy in C
All to discover it was a simple stack-overflow!
So now I have another thing to worry about. When your debugger goes nutts (and I mean litteraly nuts), it could be more than a buffer overflow!111
I honestly didn't believe this problem would get solved...
Thanks AP & Drew. [smile]
ratings++;
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement