1) values close to 0xCDCDCDCD, 0xCCCCCCCC or 0xBAADF00D indicate an uninitialised variable
2) values close to 0xDDDDDDDD and 0xFEEEFEEE indicate recently deleted variables
3) values close to 0xFDFDFDFD - it can indicate that you're reading past the beginning or end of a buffer.
4) values close to 0x00000000, or a very low value like 0x0000000B, then we're probably looking at a null pointer dereferencing
5) values close to 0xBAADF00D
6) values close to 0xdeadbbb2
///////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////
void Projectile::CalculatePhysics(float Time)
{
bool changed = false;
if(Acceleration!=Vector3(0,0,0))
{
Quaternion AccelerationDirection;
AccelerationDirection = InitialDirection;
Velocity = Velocity + (AccelerationDirection * Acceleration * Time);
changed = true;
}
if(LocalAcceleration!=Vector3(0,0,0))
{
LocalVelocity = LocalVelocity + (LocalAcceleration * Time);
changed = true;
}
if(changed)
{
Quaternion LocalDirection = mBody->getGlobalOrientation();
mBody->setLinearVelocity(Velocity + (LocalDirection * LocalVelocity)); //////////////<- here
}
if(AngularAcceleration!=Vector3(0,0,0))
{
AngularVelocity = AngularVelocity + (AngularAcceleration * Time);
mBody->setAngularVelocity(AngularVelocity);
}
}
1
Unhandled exception at 0x0049e523 in game5.exe: 0xC0000005: Access violation reading location 0xfeeefeee.
Unhandled exception at 0x0049e523 in game5.exe: 0xC0000005: Access violation reading location 0xfeeefeee.
4
Unhandled exception at 0x0049e523 in game5.exe: 0xC0000005: Access violation reading location 0x00000001.
Unhandled exception at 0x0049e523 in game5.exe: 0xC0000005: Access violation reading location 0x00000000.
Unhandled exception at 0x0049e523 in game5.exe: 0xC0000005: Access violation reading location 0x00000000.
Unhandled exception at 0x0049e523 in game5.exe: 0xC0000005: Access violation reading location 0x0000001f.
5
Unhandled exception at 0x0049e523 in game5.exe: 0xC0000005: Access violation reading location 0xbaadf00d.
Unhandled exception at 0x0049e523 in game5.exe: 0xC0000005: Access violation reading location 0xbaadf00d.
?
Unhandled exception at 0x0049e523 in game5.exe: 0xC0000005: Access violation reading location 0xabababab.
Unhandled exception at 0x0049e523 in game5.exe: 0xC0000005: Access violation reading location 0x656e6f4e.
Unhandled exception at 0x0049e523 in game5.exe: 0xC0000005: Access violation reading location 0x6c696843.
learning to debug well
Author
For most of my crashes i can usually find the problem just by stepping through code and just checking around the area where the program crashed. But there are some bugs that i just can't seem to get fixed. I keep a log of all of these and I'm wondering if anybody can offer me any insight as to how to read these crashes.
Ill give you a clip from my crashes log:
The ////////<- here indicates the crash location Visual Studio gives me.
The notes at the top are from this page: http://www.gamedev.net/reference/programming/features/debugging/page6.asp
but i am still not sure as to how to fix these problems other than making sure the pointers are NULLed when deleted and checking for nulls before accessing them.
I am wondering if anyone can give me any insight as to how i can figure out what is going wrong. Any links or tips are greatly appreciated.
On a side not this particular crash happens when i create tons of these projectile objects. like in the range of like 2k-3.5k. I have a suspicion that I am running out of memory but i have no idea how to check this. I just run the task manager and it reads my game out to about 100kb which I'm sure i have.
But I am much more interested in learning how to debug these things well.
Thank you for all help in advance =).
Things I'd look for are:
-If you're using raw pointers, make sure you set the pointers to NULL after you delete them. This prevents issues where your checking for NULL, but the pointer is just garbage (i.e. 0x0000000c or something crap like that), which would often lead to a crash when dereferencing this garbage pointer. The only instance where it doesn't really matter whether you NULL your pointers is if you are deleting them in the object's destructor and you're positive that they aren't referenced again before the destructor terminates.
I doubt you're running out of memory, unless you're doing something stupid like allocating a texture/model for each of the 2K+ projectiles.
When debugging that particular code, check to see what the "this" pointer is, and what mBody is, especially since you don't do any safety checking before dereferencing the pointer.
-If you're using raw pointers, make sure you set the pointers to NULL after you delete them. This prevents issues where your checking for NULL, but the pointer is just garbage (i.e. 0x0000000c or something crap like that), which would often lead to a crash when dereferencing this garbage pointer. The only instance where it doesn't really matter whether you NULL your pointers is if you are deleting them in the object's destructor and you're positive that they aren't referenced again before the destructor terminates.
I doubt you're running out of memory, unless you're doing something stupid like allocating a texture/model for each of the 2K+ projectiles.
When debugging that particular code, check to see what the "this" pointer is, and what mBody is, especially since you don't do any safety checking before dereferencing the pointer.
Quote:Original post by dashurc
Things I'd look for are:
-If you're using raw pointers, make sure you set the pointers to NULL after you delete them. This prevents issues where your checking for NULL, but the pointer is just garbage (i.e. 0x0000000c or something crap like that), which would often lead to a crash when dereferencing this garbage pointer. The only instance where it doesn't really matter whether you NULL your pointers is if you are deleting them in the object's destructor and you're positive that they aren't referenced again before the destructor terminates.
I doubt you're running out of memory, unless you're doing something stupid like allocating a texture/model for each of the 2K+ projectiles.
When debugging that particular code, check to see what the "this" pointer is, and what mBody is, especially since you don't do any safety checking before dereferencing the pointer.
Yeah you really shouldn't be getting these kinds of bugs unless you are doing something stupid or not following good practices.
I find logic bugs to be hardest to deal with myself!
Logic Bug
Symptom: The program runs without crashing, but behaves incorrectly, e.g. allowing you to select weapons you do not currently have, or declaring the game won/lost at the wrong time.
The last couple of bugs that took me a while to figure out were logic related namely some collision detection code not working properly due to sprite values not being set as I assumed there were.
If I get an "access violation" crash those are pretty easy to fix since it usually means I went out of bounds somewhere or tried to access some memory I shouldn't of.
If you are using Visual C++ try some breakpoints. You can check your variables's values then.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
