Jump to content

  • Log In with Google      Sign In   
  • Create Account


[C++] Elusive access violation error


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
8 replies to this topic

#1 Rubiks14   Members   -  Reputation: 143

Like
0Likes
Like

Posted 10 April 2013 - 09:41 PM

So here's the deal, I've been working on a roguelike game in c++ using the advanced windows console functions in wincon.h. I have a randomly generated map and I'm drawing it to a screen. Every once in a blue moon when I'm running the program it will give me an access violation error on program close. I can run the program probably 50 times and if I'm lucky (unlucky actually) the error will show up.

 

I'm using codeblocks as my IDE and have the debugger set to break on an exception. I have been unable to actually recreate the access violation while using the debugger. It only seems to occur when I do a basic run of the program. It doesn't crash the program or lock up, it just gives the error code on close.

 

There is too much code to post here but you can look at it on github: https://github.com/Rubiks14/ASCII . I believe the error is happening in map.h but it might not hurt to look into screen.h and screen.cpp as well. Also I'm sorry for the craziness of the code in advance. Some of the comments are relevent but others need to be updated. I know there are a few things that need to be broken down into more functions and some stuff that would work better if passed by reference (the vectors), I'm just trying to eliminate this bug before altering anything else and before adding any new features.

 

One more thing. I think the problem is somewhere in the drawing procedures for the map or screen class.

 

 

EDIT: Fixed broken link


Edited by Rubiks14, 10 April 2013 - 11:27 PM.


Sponsor:

#2 Cornstalks   Crossbones+   -  Reputation: 6966

Like
4Likes
Like

Posted 10 April 2013 - 10:06 PM

1. Don't use identifiers starting with an underscore followed by an upper case letter (like _SCREEN_H_). They're reserved for the implementation

 

2. Don't use identifiers that contain two consecutive underscores (anywhere in the identifier) (like __CScreen). They're reserved for the implementation.

 

3. I honestly have no idea why you're doing a typedef for naming your classes in this C-like manner.

 

4. Might I suggest using constructors instead of Create*** functions?

 

I couldn't find something that looked like a probable cause of your error. What's the stack trace?


[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

#3 Rubiks14   Members   -  Reputation: 143

Like
0Likes
Like

Posted 10 April 2013 - 10:20 PM

Thanks for the advice on the naming with the underscores and typedef. I don't have any of the room/map in a class. The map is just a struct and the features are just vectors of CHAR_INFO type.

 

Unfortunately I haven't been able to see the stack trace because I haven't been able to recreate it with the debugger running.



#4 Cornstalks   Crossbones+   -  Reputation: 6966

Like
2Likes
Like

Posted 10 April 2013 - 10:59 PM

I forgot to point out that your link is broken. It's got a period at the end of it and shouldn't.

 

Thanks for the advice on the naming with the underscores and typedef. I don't have any of the room/map in a class. The map is just a struct and the features are just vectors of CHAR_INFO type.

Structs can have constructors too.

 

Unfortunately I haven't been able to see the stack trace because I haven't been able to recreate it with the debugger running.

You can try building a release version with debug info.


[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

#5 Rubiks14   Members   -  Reputation: 143

Like
0Likes
Like

Posted 10 April 2013 - 11:52 PM

Unfortunately after doing that I still haven't come up with anything useful in helping me track down the error (it didn't occur). The only thing I can think to start doing now is disabling things one at a time to see if it keeps coming. It's too late for me to keep looking tonight. I'll give it another go tomorrow.



#6 phil_t   Crossbones+   -  Reputation: 3107

Like
0Likes
Like

Posted 11 April 2013 - 12:26 AM

You should be able to setup just in time debugging, so that your debugger automatically attaches to your process when it crashes.

 

It shows how here:

http://msdn.microsoft.com/en-us/library/windows/desktop/bb204634(v=vs.85).aspx

 

 

Not being able to get a call stack for a crash is not a good situation to be in!



#7 NightCreature83   Crossbones+   -  Reputation: 2650

Like
0Likes
Like

Posted 11 April 2013 - 03:53 AM

Can you give us the access violation as in the 3 numbers it should spit out, as it often contains the information you are interested in.


Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, Mad Max

#8 MrP   Members   -  Reputation: 565

Like
2Likes
Like

Posted 11 April 2013 - 06:23 AM

The access violation is occurring when you are adding your features to the mapStorage vector in Map.h.

 

The feature location coordinates you produce have a lower limit of (1, 1) and an upper limit of (MapSize.X - 1, MapSize.Y - 1) which is perfectly valid, however when the Y coordinate is at the upper limit of this range and you attempt to access the tile below (e.g. line 260) the resulting index will be outside of the legal range of the vector which produces an access violation.



#9 Rubiks14   Members   -  Reputation: 143

Like
0Likes
Like

Posted 11 April 2013 - 01:04 PM

MrP,

 

That seems to have fixed it. I didn't think about that. I had set the minimum to (1,1) to prevent from reaching memory in front of the vector but didn't think about it in the sense of after the vector.

 

Thank you and everyone else who assisted with this. Now I can clean this code up and finally move on to actually making this into a game.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS