Access violation .... the memory could not be read
Author
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?
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.
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.
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.
Author
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. :(
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. :(
Author
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
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.
Author
Your debugging suggestions have given me another idea. I think I'll try to get remote debugging to work. Perhaps that will help.
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. :(
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. :(
Quote:Original post by Red AntThat 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?)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
Perhaps someone else here knows how to get the function from the address (I don't)
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.
Can you get a call stack from when the access violation occurs? RtlEnterCriticalSection is called from various other Win32 functions.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
