Skip to main content
gamedev.net
🔒 Locked

Visual Studio 6 - Debug Issue.... (Solved, stack-overflow)

Started by ProcedureX Jan 18, 2005 at 11:31 PM 14 replies 3.5k views
Original Post
ProcedureX
ProcedureX
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]
avianRR
avianRR
Quote:
Original post by ProcedureX
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.)


Could you be more specific?
Cause what?
Which two values?
------------------------------Piggies, I need more piggies![pig][pig][pig][pig][pig][pig]------------------------------Do not invoke the wrath of the Irken elite. [flaming]
ProcedureX
ProcedureX
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?!)
Zanthos
Zanthos
My only suggest from what I can see is that it could be an overflow problem of some sort... possibly.
ProcedureX
ProcedureX
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.
ProcedureX
ProcedureX
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]
ProcedureX
ProcedureX
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]
ProcedureX
ProcedureX
Bump: someone must be able to explain this.. [depressed]
Gav
Gav
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.

===========================There are 10 types of people in the world. Those that understand binary and those that don't.( My views in no way reflect the views of my employer. )
ProcedureX
ProcedureX
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];
ProcedureX
ProcedureX
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]
Drew_Benton
Drew_Benton
Here is one suggestion - make

unsigned short intHook


into

unsigned short int intHook


If this does not work I have another suggestion typed.

- Drew
Drew_Benton
Drew_Benton
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
ProcedureX
ProcedureX
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++;
antareus
antareus
The stack, by default, is something like one megabyte. I think it gets expanded if it needs to. In the event of a stack overflow, a structured exception should get raised which you can check for. I always set VS.NET to break immediately upon an exception getting thrown.
--God has paid us the intolerable compliment of loving us, in the deepest, most tragic, most inexorable sense.- C.S. Lewis

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.