What is this Read Access violation Exception due to?

[BarefootGuy]

My program crashes and a dialog box shows

"Unhandled exception at 0x3aaf1aea (pmsqlsrv.dll) in java.exe: 0xC0000005:
Access violation reading location 0x3ac60880."

The statement shown as causing the crash is
m_pDatabase->m_pIDBCreateCommand->CreateCommand();

In the watch window,
"this" pointer value for the containing object is 0x7395fcaf
m_pDatabase is 0xffff8810 (does it look like a valid address?)
m_pDatabase->m_pIDBCreateCommand CXX0030: Error: expression cannot be evaluated

The addresses shown in the crash dialog box - 0xC0000005 and 0x3ac60880 I don't know what they are. Does this mean that the dll (pmsqlsrv.dll) itself is corrupted and the crash is in reading the code segment rather than in accessing the data?

Please help before I shoot myself.

[VictorN]

...
The statement shown as causing the crash is
m_pDatabase->m_pIDBCreateCommand->CreateCommand();

In the watch window,
"this" pointer value for the containing object is 0x7395fcaf
m_pDatabase is 0xffff8810 (does it look like a valid address?)

Who knows? How and where (if ever) m_pDatabase was initialised?

...
m_pDatabase->m_pIDBCreateCommand CXX0030: Error: expression cannot be evaluated

It looks like m_pDatabase->m_pIDBCreateCommand is not a valid pointer that also may or may not be the result of invalid m_pDatabase pointer.

[BarefootGuy]

The "this" object itself seems invalid, as many of its members are shown as "<Bad Ptr>" in the watch window. But the memory error detection tool shows no error prior to the crash point, only a "Invalid read" at the crash point. What approach could I take to find how the pointer becomes invalid? I tried writing the this pointer value to a file just before the statement that is crashing, but it won't even write to the file even though the control should have passed through those lines.

[Paul McKenzie]

What approach could I take to find how the pointer becomes invalid?

Use your compiler's debugger, and then single step through your code until you see the issue.

I tried writing the this pointer value to a file just before the statement that is crashing,

The point where your program crashes is usually not the point where the problem originated. You could have corrupted memory long before that statement is executed. So you shouldn't be writing anything, as the state of your program is unstable.

The addresses shown in the crash dialog box - 0xC0000005 and 0x3ac60880 I don't know what they are.

0xC0000005 is an access violation.

Does this mean that the dll (pmsqlsrv.dll) itself is corrupted and the crash is in reading the code segment rather than in accessing the data?

It means you're program is mismanaging pointers or dynamic memory allocation.

Regards,

Paul McKenzie

[VictorN]

What approach could I take to find how the pointer becomes invalid?

You have to debug your code, at least around all the places where m_pDatabase is used.

[BarefootGuy]

You have debug your code, at least around all the places where m_pDatabase is used.

Actually the crash doesn't happen consistently, it is intermittent. Even the location of the crash is not the same everytime. As one of you said, the memory corruption could have happened long ago and I'm only seeing the effect in different places. So I'm asking what approach I could take to detect where the memory corruption is occuring. Memory error detection tools like Memory Validator only shows the error at the time of crash, with a message like "Invalid read of 4 bytes" etc.

[esteenbrink]

Also make sure that for all pointers used, you NULL them in the constructor of the class where they are defined.
This way you can find out if you ever set the pointer in your code.

Kind regards.

[Paul McKenzie]

Actually the crash doesn't happen consistently, it is intermittent. Even the location of the crash is not the same everytime. As one of you said, the memory corruption could have happened long ago and I'm only seeing the effect in different places.

Sounds like a buffer overwrite. That can be caused by mismanagement of pointers, writing beyond the boundaries of an array or allocated space, incorrect or invalid usage of the C++ language, etc. The latter (where you are using C++ improperly) is hard to detect if you do not know that you're using C++ improperly and instead believe the code is OK. Things like using malloc() or memcpy() on non-POD types is one such error.

So I'm asking what approach I could take to detect where the memory corruption is occuring.

The approach is to debug further until you find what's causing the issue. Sorry, but that's it.

Memory error detection tools like Memory Validator only shows the error at the time of crash, with a message like "Invalid read of 4 bytes" etc.

Boundschecker can tell if there are memory overruns at the time they occur, but BoundsChecker is not cheap.

The bottom line is this -- memory overwrites and debugging them are part of the learning process of using C++. Random crashes due to such mistakes are commonplace. That's why C++ introduced smart pointers, containers, etc. so that you're not doing the manual memory management yourself.

Regards,

Paul McKenzie

[Lindley]

Valgrind can be helpful for this sort of thing but is not available for Windows.

Another option is to first identify some point in the run when m_pDatabase is valid, and then set a watchpoint on that memory location to trigger the debugger as soon as it is modified. Note, this can greatly slow down execution speed.

[JohnW@Wessex]

On Windows you can sprinkle a few assert(_CrtCheckMemory) calls around the code when running in debug mode. These check the integrity of allocated memory blocks.

By seeing where the assert occurs you can move the checks around and home in on the offending area.

http://msdn.microsoft.com/en-us/libr...=vs.80%29.aspx