Wednesday, May 02, 2012 12:31 AM
I got the following exception. How to handle such problems? Thanks.
First-chance exception at 0x01fa52a0 (mfc90d.dll) in a.exe: 0xC0000005: Access violation reading location 0x000000000e18bf40.
Unhandled exception at 0x01fa52a0 (mfc90d.dll) in a.exe: 0xC0000005: Access violation reading location 0x000000000e18bf40.
Wednesday, May 02, 2012 1:19 AM
Use the debugger call stack window. It will show you exactly where in your code the problem began. As you click on each line of the stack display the edit window shows the line of code that executed. Using this you can backtrack through functions, that called functions, that called functions, etc.
Wednesday, May 02, 2012 3:18 AMThanks. But this problem is always there. Sometimes works fine. Any more ideas?
Wednesday, May 02, 2012 3:53 AM
But this problem is always there. Sometimes works fine.Those statements appear to contradict each other.
The first says the problem is always there, and the
second says it isn't always there.
If it's intermittent, you may be using an uninitialized
pointer somewhere. If it has random contents - whatever
happens to be in memory at the time - then sometimes the
random address will be within your program's address
space and other times it won't be.
Wednesday, May 02, 2012 3:57 AM
Sorry. It should be :
But this problem is NOT always there. Sometimes works fine.
Thanks for your idea. I will research the code for it.
Wednesday, May 02, 2012 11:18 PM
Did not find uninitialized pointer.
However, I found out this:
If the visual studio is set as "Debug", it works fine.
If the visual studio is set as "Release", the error happens.
Any further ideas? Thanks.
Wednesday, May 02, 2012 11:41 PM>If the visual studio is set as "Debug", it works fine.
>If the visual studio is set as "Release", the error happens.
Which further suggests that you may have an initialization
problem. In Debug builds uninitialized variables are preset
to a special pattern to assist in tracking memory overwrites,
etc. In Release builds this isn't done, so uninitialized
variables have a random value.
In addition to using an uninitialized pointer, look for other
cases where a variable is being used without initializing
it first. This can be in loops - where the controlling
variable hasn't been set at the start. e.g. -
for(int n; n != x; ++n) // n not set, may cause buffer overrun
You should make sure you compile with highest warning level
set and be sure to check the cause of *all* warnings from
Passing invalid values as arguments to functions - including
library functions - may also cause access violations, etc.
One other difference between Debug and Release builds - by
default Debug builds have all optimizations off and Release
builds have optimizations enabled. Try turning off all
optimizations in your Release build's project properties
and rebuild. See if the problem goes away.
Thursday, May 03, 2012 12:18 AM
Or possibly a race condition.
If the application is multithreaded then the optimisations may cause one to appear. A thread that may end up cleaning itself up after the last time another one accesses it for the last time may suddenly clean itself up before.
This is a signature
Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.
Do you want Visual Studio 11 Express to be freely installable on Windows 7 and able to write regular C++ applications? Please vote for this.
Thursday, May 03, 2012 6:28 AM
Did not find uninitialized pointer.