AccessViolationException in Release mode (C++)?

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.

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.

Thanks. I think you're right. We've had lots of problems with leaks (I guess it's par for the course).

We're using the MS memory leak tools: _CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_FILE); _CrtSetReportFile( _CRT_WARN, _CRTDBG_FILE_STDERR); _CrtSetBreakAlloc( 665); _CrtMemState state; _CrtMemCheckpoint( & state); Any thoughts on how to track this down? – Joe Jul 2 '09 at 15:49.

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.

I'll look into this. Thanks. – Joe Jul 2 '09 at 15:19 Didn't find anything.

– Joe Jul 2 '09 at 15:56 Did it still crash when you ran the . Exe directly? – CodeFusionMobile Jul 2 '09 at 16:00 I ran the .

Exe directly and it does still throw the exception. – Joe Jul 2 '09 at 16:12.

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.

Thanks very much. The first possibility seems more likely than the second to me. I say this because I'm able to get rid of the exception by changing the size of some strings.

If it was a pointer initialization problem, then I should still see the exception, right? – Joe Jul 2 '09 at 16:25 @Joe - if it was an initialisation pointer you won't see it in debug as both @eidolon and I point out by default VC initialises local variables in debug mode. – ChrisF Jul 2 '09 at 16:38 Right.

I'm able to make the exception go away by changing string sizes in Release mode. – Joe Jul 2 '09 at 16:44.

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.

Interesting, I reduced the size of the string that's used to initialize the const std::string variable and saw the exception go away. Does this mean that the string is overrunning it's variable?Thanks. – Joe Jul 2 '09 at 15:26 As I said it's a while since I've done C++ and never with managed code, but if your not using the CLR then I'd guess your code isn't managed.

If changing the string changes the behaviour then it would indicate that that's where the problem lies, but actually sitting down and debugging the code it's always going to be difficult to be certain. – ChrisF Jul 2 '09 at 15:32 Would managed code stop buffer overruns? I thought the primary benefit was garbage collection, but I'm no expert.

– David Thornley Jul 2 '09 at 16:53 @David I don't think it would stop buffer overruns. I was thinking more about memory management and uninitialised pointers. – ChrisF Jul 2 '09 at 17:41.

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.

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 thunderguy.com/semicolon/2002/08/15/visu... (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.

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.

Thanks. I'll look into this. – Joe Jul 6 '09 at 13:12.

I'm not sure if mine's a different problem altogether, but in my program, control passes from managed C# to managed C++ to unmanaged C++ and I'm having the AccessViolationException thrown in Release mode which points specifically to the line where I call a function in the unmanaged side from the managed C++ side. I've been trying all the above approaches with little luck so far. Thanks, Kaushik.

I ended up using a work around, so I'm not sure how much help I can be. Basically, I greatly reduced the number of global const std::string variables that I was using. This did the trick.

Good luck. – Joe Sep 11 '09 at 16:48.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.