Dereferencing deleted pointers always result in an Access Violation ??

Question

I have a very simple C++ code here:

char *s = new char[100];
strcpy(s, "HELLO");
delete [] s;
int n = strlen(s);

If I run this code from Visual C++ 2008 by pressing F5 (Start Debugging,) this always result in crash (Access Violation.) However, starting this executable outside the IDE, or using the IDE's Ctrl+F5 (Start without Debugging) doesn't result in any crash. What could be the difference?

I also want to know if it's possible to stably reproduce the Access Violation crash caused from accessing deleted area? Is this kind of crash rare in real-life?

Answer 1

Accessing memory through a deleted pointer is undefined behavior. You can't expect any reliable/repeatable behavior.

Most likely it "works" in the one case because the string is still "sitting there" in the now available memory -= but you cannot rely on that. VS fills memory with debug values to help force crashes to help find these errors.

Answer 2

Dereferencing a pointer after delete is undefined behavior - anything can happen, including but not limited to:

• data corruption
• access violation
• no visible effects

exact results will depend on multiple factors most of which are out of your control. You'll be much better off not triggering undefined behavior in the first place.

Answer 3

Usually, there is no difference in allocated and freed memory from a process perspective. E.g the process only has one large memory map that grows on demand.

Access violation is caused by reading/writing memory that is not available, ususally not paged in to the process. Various run-time memory debugging utilities uses the paging mechanism to track invalid memory accesses without the severe run time penalty that software memory checking would have.

Anyway your example proves only that an error is sometimes detected when running the program in one environment, but not detected in another environment, but it is still an error and the behaviour of the code above is undefined.

Answer 4

The difference is that a debugger, and debug libraries, and code built in "debug" mode, likes to break stuff that should break. Your code should break (because it accesses memory it no longer technically owns), so it breaks easier when compiled for debugging and run in the debugger.

In real life, you don't generally get such unsubtle notice. All that stuff that makes things break when they should in the debugger...that stuff's expensive. So it's not checked as strictly in release. You might be able 99 times out of 100 to get away with freeing some memory and accessing it right after, cause the runtime libs don't always hand the memory back to the OS right away. But that 100th time, either the memory's gone, or another thread owns it now and you're getting the length of a string that's no longer a string, but a 252462649-byte array of crap that runs headlong into unallocated (and thus non-existent, as far as you or the runtime should care) memory. And there's next to nothing to tell you what just happened.

So don't do that. Once you've deleted something, consider it dead and gone. Or you'll be wasting half your life tracking down heisenbugs.

Answer 5

The executable with debug symbols is able to detect some cases of access violations. The code to detect this is contained in the executable, but will not be triggered by default.

Here you'll find an explanation of how you can control behaviour outside of a debugger: http://msdn.microsoft.com/en-us/library/w500y392%28v=VS.80%29.aspx

Answer 6

I also want to know if it's possible to stably reproduce the Access Violation crash caused from accessing deleted area?

Instead of plain delete you could consider using an inline function that also sets the value of the deleted pointer to 0/NULL. This will typically crash if you reference it. However, it won't complain if you delete it a second time.

Is this kind of crash rare in real-life?

No, this kind of crash is probably behind the majority of the crashes you and I see in software.