AccessViolationException in Release mode (C++) - memory

Question

I'm getting the following exception when I run my application in Release mode from Visual C++.
Unhandled Exception:
System.AccessViolationException:
Attempted to read or write protected
memory. This is often an indication
that other memory is corrupt. at
_cexit() at .LanguageSupport._UninitializeDefaultDomain(Void
* cookie) at .LanguageSupport.UninitializeDefaultDomain()
at
.LanguageSupport.DomainUnload(Object
source, Eve ntArgs arguments) at
.ModuleUninitializer.SingletonDomainUnload(Objec
t source, EventArgs arguments)
This doesn't happen in Debug mode. Initially, I saw this exception on my home computer, but not work computer. When I continued to develop on my work computer, I ended up bumping into it.
Also, I found that when I added three const std::string variables the exception was thrown. If I removed then then all went well.
Another piece of information: I've found that turning off all the compiler optimizations in Release mode makes the exception go away
Something fishy is going on. Any ideas on how to track this down?
Thanks for the help,
Joe

Answer 1

Joe, you have a memory leak.
You're probably trying to use some memory that has been deleted.
See this article for common causes of memory leaks, and how to identify them, otherwise, search for "C++ memory profiler" + your compiler/platform, it'll give links to Memory profilers suitable for your compiler and platform, these will help track down the memory leak by watching how your program uses memory as it runs.
Hope this helps.
EDIT
How to track it down? This is off the top of my head, there may be better advice else where . . .
Find where the code crashes, it'll be when accessing the contents of some pointer (or deleting a pointer).
The problem is that that pointer has either a) never been assigned b) is already deleted.
Go through all references to pointers of that type, are they used in copy ctors/assignment operators?
If so, are it's contents being copied or just the pointer?
If just the pointer then is the containing class trying to delete the pointer? If so the first class to die will succeed, the second will throw an access violation.
If you don't explicitly code copy ctors and operator=, then you should hide them (declare private prototypes but don't implement them), this stops the compiler from generating default implementations for you.
When you hide them you'll get compiler errors everywhere they're being used, it might be that you can clean these up, or that you need to implement the copy ctor and operator= for each class.
I'm on vacation from tomorrow or two weeks, email me direct today (follow the link on my SO user page) if you've any questions on this.

Answer 2

Do you have any code that is #defined out for debuging in your code?
i.e.
#ifndef _DEBUG
//release only code such as liscensing code
#endif
That's one thing that could be causing the problem, and I've run into it before as well.
Another possibility is a VS issue (or whatever IDE you're using).
Try running the release .exe directly instead of through the develoment environment and see if you still have the same issue.

Answer 3

It's a while since I've done C++ "in anger" so to speak, so some (or indeed all) of what I say below may well be out of date.
Are you using managed C++? If not then it sounds like an uninitialised pointer. It used to be the case that all pointers were nulled in debug & I recall something about turning this behaviour off, but I can't remember the full details right now.
Are the strings overrunning their variables? Unlikely with std::string, but worth eliminating.

Answer 4

Couple of possibilities:
I would guess that you are reading/writing past local array end. In debug builds this may work, as memory is not tightly allocated. In release builds this is more likely to cause problems, depends on what is allocated right next to the array.
Another possibility is that you have an uninitialized pointer somewhere. VC default initializes local variables in debug mode, but not in release mode. Thus code like:
int* p;
if (p != NULL) { /* do something */ }
Typically fails on release mode.

Answer 5

The error message is strongly suggesting you have a memory issue, probably overwriting memory. These are hard to find, but you can find some possible solutions googling "visual c++ memory corruption tool".
The thing about memory corruption is that it's unpredictable. It doesn't necessarily have any consequences, and if it does they may not result in a crash. Crashing like that is good, because it informs you you've got a problem.
Fiddling with debug vs. release, adding or removing parts of code, changing optimization options and the like is unlikely to solve the problem. Even if it does, it's likely to crop up if any changes are made.
So, you've got a memory corruption problem. Those are almost always difficult to find, but there are tools. You need to fix that problem.
You might also look at your shop practices. Do you use less safe constructs (new arrays rather than vector<>, say)? Do you have coding standards to try to reduce risk? Do you have code reviews? Memory corruption can be insidious and damaging, and you want to avoid it as much as possible.

Answer 6

What your getting is a system exception from the OS. These are not handled because they are not C++ exception. However you can convert then into a C++ exception and catch them like a normal exception.
There is a great article here http://www.thunderguy.com/semicolon/2002/08/15/visual-c-exception-handling/ (page 3) that shows how to create a Windows Exception class that will catch the exception using the _set_se_translator method and throw a C++ exception. The great thing is you can get a stack from the EXCEPTION_RECORD structure, although your'll have to add that functionality to process the structure, but it will help narrow your search for that access violation.

Answer 7

I think the issue here is uninitialized local variable.
In Debug mode generally the variables get initialized and you don't get any exceptions.
But errors may occur in release mode because of this.
Try to look for uninitialized variable whose access may cause exception.
Suppose you have boolean local variable.
bool bRet;
In debug build bRet will get initailized to 0 and your code just works fine .
But in release it won't be 0 , it would be some random value and your code might be doing something based on bRet .It may later cause an exception because bRet value is wrong.