Jump to content
  • Advertisement
Sign in to follow this  
Corvwyn

Access violation reading location ....

This topic is 4674 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm working on an engine in DirectX9. The reason I'm not posting this in the DX forum is that this part isn't really connected to DX. I've created the System and Graphics core (only the basics though). I was creating the GameLogic core and for some reason I get this error when I exit my program: First-chance exception at 0x77d513da in Engine.exe: 0xC0000005: Access violation reading location 0x003c7000. Unhandled exception at 0x77d513da in Engine.exe: 0xC0000005: Access violation reading location 0x003c7000. The debugger stops at the end of the MsgProc. What's wierd about this error is that when I chop the GameLogic part down to only one skeleton class with nothing in it, I still get the problem. I haven't even integrated the GameLogic part into the engine at all, not a single instance. When I exclude the GameLogic files from the project everything works. If put the files back again (w/one skeleton class) after exluding them it works. If I simply add a constructor everything goes haywire again... Any have a clue to what the hell this could be? I'm using VC++ 2005 by the way. Edit: It seems like Visual Studio doesn't update when I build or something. Have tried cleaning the solution/project, but to no avail. [Edited by - Corvwyn on January 1, 2006 10:42:44 AM]

Share this post


Link to post
Share on other sites
Advertisement
looks like a bad function pointer being referenced (calling a virtual function that doesn not exists for an object, or the linker got screwed up and linked to an invalid fonction pointer), or calling an object that has been deleted already, possibly to do with objects being statically created (static CGameObject xMyGameObject)...

I'd lean towards an invalid reference to an object that's not present anymore, since it happens on exit, and it is to do with windows messaging.

OK, not very clear, but I'm kinda hangovered, but try putting a breakpoint on the game object destructor, and when the message WM_QUIT is received, or something like that... With the call stack, you should be able trace the shutting-down process.

also, try to see what's at the address 0x003c7000 (can't remember if it's actually a valid address for a program allocation).

Share this post


Link to post
Share on other sites
This definately feels like a derefrencing error in a destructor. Put breakpoints on your destructors and step through them all on exit to see where you get the seg fault.

Share this post


Link to post
Share on other sites
This was related to a destructor. I still have some questions though

I have a static global Application object:
static cApplication *g_pApp = NULL;

This is what I did to fix it:

// snippet from MsgProc
case WM_DESTROY:
g_pApp->Shutdown();
//delete g_pApp;
PostQuitMessage(0);
return 0;
// snippet end

// Same content as ~cApplication had:
void cApplication::Shutdown()
{
if(m_Graphics != NULL)
delete m_Graphics;
}







Isn't ~cApplication() and Shutdown() doing the same thing? Or are the destructor and Shutdown() functions simply in different memory locations, so a new error is just waiting to happen?

So the reason for this error is that it conflicted with the memory space of my new classes? Why would this happen even though I didn't even create an instance of the new classes? Or am I completely off?

[Edited by - Corvwyn on January 1, 2006 8:32:49 PM]

Share this post


Link to post
Share on other sites
If I follow the issue is whether you still have allocated the memory that you are accessing which would include whether what you are deleting is still allocated or already been deleted once.

Share this post


Link to post
Share on other sites
always set pointers to NULL after deletion and before new |at constructors). Always always always.


// snippet from MsgProc
case WM_DESTROY:
g_pApp->Shutdown();
delete g_pApp;
g_pApp = NULL;
PostQuitMessage(0);
return 0;
// snippet end

// Same content as ~cApplication had:
void cApplication::Shutdown()
{
if(m_Graphics != NULL)
delete m_Graphics;
m_Graphics = NULL;
}

// Same content as ~cApplication had:
cApplication::~cApplication()
{
Shutdown();
}



if the destructor is the same as shutdown, call shutdown then.

Share this post


Link to post
Share on other sites
C++ hasn't got automated garbage collecting. A destructor will thus only do what you tell it to do. If you want something to be cleaned by the destructor, you have to call it in it's scope.

Share this post


Link to post
Share on other sites
Thanks oliii. I should have thought of that, silly me. I have to stop taking long breaks between programming C++.

Share this post


Link to post
Share on other sites
A good practise I find, is that sometimes 'dead' pointers don't always equal exactly 0x00000000. Some may be equal to 0x00000001 etc... What I do, is instead of doing if ( pPointer != NULL ), I do if ( (long)pPointer >= 256 ). This is a guarantee that even if the pointer isn't exactly NULL, you won't get delete or delete [ ] errors. This is a rare occurrence, but when it does happen, it can be very hard to track down.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!