Jump to content
  • Advertisement
Sign in to follow this  
Red Ant

Access violation .... the memory could not be read

This topic is 3888 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

Hello, A C++ application of mine occasionally procudes a sporadic access violation after running fine for hours. Since this error is so rare, it is very hard to catch it while running the program in the debugger. :( My only clue is an error message such as "Access violation! The instruction at 0xblahblahblah referenced memory at 0x00000blahblah. The memory could not be read." Now much to my shame I must confess that while I'm a relatively solid C/C++ coder, my assembler knowledge is very limited. Is there any way I can use the instruction/memory addresses provided by the error message to track down the bug? Can anyone give me a few pointers in the right direction? Do I need to put my executable through a disassembler or something like that?

Share this post


Link to post
Share on other sites
Advertisement
Running your code through the debugger should give you a call stack you can use.

What's the actual address? If it's 0x00000000, or very close to zero), then that's almost certainly a null pointer somewhere.

Dissasembling your app probably won't give you any useful information.

Share this post


Link to post
Share on other sites
Quote:
Original post by Red Ant
Hello,

A C++ application of mine occasionally procudes a sporadic access violation after running fine for hours. Since this error is so rare, it is very hard to catch it while running the program in the debugger. :( My only clue is an error message such as "Access violation! The instruction at 0xblahblahblah referenced memory at 0x00000blahblah. The memory could not be read." Now much to my shame I must confess that while I'm a relatively solid C/C++ coder, my assembler knowledge is very limited. Is there any way I can use the instruction/memory addresses provided by the error message to track down the bug? Can anyone give me a few pointers in the right direction? Do I need to put my executable through a disassembler or something like that?


Well, for starters you could have shown the address instead of "0000blahblah". The first half of it looks like it's probably a null pointer you're trying to dereference.

As for how you can diagnose it yourself? Use the debugger. At the point where it crashes, you'll know the address it tried to access, and then you just have to look through your local variables to find out which one of them contained that address. Then you know that variable contained an invalid pointer, and you can backtrack from there to figure out how that happened.

Share this post


Link to post
Share on other sites
Oh how I wish I could run it in the debugger! Alas .. no such luck, mainly because of the error being so damn sporadic that it never happens when I got the app running in the debugger.

EDIT: There are plenty other reasons why I can't run it in the debugger and hope to catch the error that way. The application in question is a CORBA server that interfaces with PROFIBUS plug-in cards, etc ... on my development machine, the PROFIBUS cards aren't present and the whole PROFIBUS interface isn't even loaded. The machines where the application is actually used productively don't (and can't) have Visual Studio installed. :(

Share this post


Link to post
Share on other sites
Quote:
Original post by Spoonbender
Well, for starters you could have shown the address instead of "0000blahblah". The first half of it looks like it's probably a null pointer you're trying to dereference.


the instruction was: 0x7c901010
the memory location: 0x00000014


Share this post


Link to post
Share on other sites
Quote:
Original post by Red Ant
Oh how I wish I could run it in the debugger! Alas .. no such luck, mainly because of the error being so damn sporadic that it never happens when I got the app running in the debugger.

EDIT: There are plenty other reasons why I can't run it in the debugger and hope to catch the error that way. The application in question is a CORBA server that interfaces with PROFIBUS plug-in cards, etc ... on my development machine, the PROFIBUS cards aren't present and the whole PROFIBUS interface isn't even loaded. The machines where the application is actually used productively don't (and can't) have Visual Studio installed. :(

So you settled on a platform without even considering the debugging implications. Oops.

Your best bet at this point is to get VS (probably in remote mode) working on that machine. Failing that, instrument your application to produce good debugging dumps, and examine those dumps. Your problem is almost certainly the execution of a member function on a null pointer, but without a stack trace this is likely to be a completely useless diagnosis.

Share this post


Link to post
Share on other sites
Your debugging suggestions have given me another idea. I think I'll try to get remote debugging to work. Perhaps that will help.

Quote:
Sneftel said
So you settled on a platform without even considering the debugging implications. Oops.


Silly, I know. Not my decision, though. I inherited this project from a coworker half a year ago. I had to do some serious refactoring to even enable the application to run from anywhere other than C:\testconfiguration. I also had to switch from static DLL linking to runtime linking to get the program to run on ANY development machine at all. It is all such a horrible mess. :(

Share this post


Link to post
Share on other sites
Quote:
Original post by Red Ant
Quote:
Original post by Spoonbender
Well, for starters you could have shown the address instead of "0000blahblah". The first half of it looks like it's probably a null pointer you're trying to dereference.


the instruction was: 0x7c901010
the memory location: 0x00000014
That looks like you're accessing a member variable in a class which is a null pointer. You can find out what function it was in from the instruction address, that's in a windows DLL (Kernel32 maybe?)

Perhaps someone else here knows how to get the function from the address (I don't)

Share this post


Link to post
Share on other sites
According to Process Explorer, 0x7c901010 is in ntdll.dll, which loads at 0x7c900000. And according to Depends, RtlEnterCriticalSection's entry point is 0x00001005, which looks like it would be correct.

Can you get a call stack from when the access violation occurs? RtlEnterCriticalSection is called from various other Win32 functions.

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!