C++ stack and heap corruption

I was recently reading about stack & heap corruption in C & C++. The author of the website demonstrates stack corruption using below example.

#include<stdio.h> 
 int main(void) 
 { 
     int b = 10; 
     int a[3]; 
     a[0] = 1; 
     a[1] = 2; 
     a[2] = 3; 

     printf(" b = %d \n",b); 
     a[3] = 12; // oops it is invalid, behaviour is undefined
     printf(" b = %d \n",b); 
     printf("address of b= %x\n",&b);
     printf("address of a[3]= %x\n",&a[3]);
     return 0; 
 }

I tested above program on visual studio 2010 compiler (VC++) & it gives me runtime error that says:

stack around variable a gets corrupted

Now my question: is stack corrupted for lifetime or it is only for the time during when above erroneous program was being executed?

Same way, I know that deleting same pointer twice might do really bad things like heap corruption. The following code:

int* p=new int();
delete p;
delete p;  // oops disaster here, undefined behaviour

When the above code fragment executes the VC++ shows heap corruption error at runtime.

Solution

You have to be careful with terminology here. Will the stack be "corrupted" for the remainder of your program's life? It may be; it may not be. In this instance you've only corrupted data within the current stack frame, so once you're out of that function call, in practice your "corruption" will have gone.

But that's not quite the whole story. Since you've overwritten a variable with bytes that aren't supposed to be there, what knock-on effects might that have on your program? The consequences of this memory corruption could feasibly be logically passed on to other function scopes, or even other computers if you're sending this data over a network connection and the data is no longer in the expected form. (Typically, your data protocol will have safety features built into it to detect and discard unexpected forms of data; but, that's up to you.)

The same is true of heap corruption. Any time you overwrite the bytes of something that is not supposed to be overwritten, and any time you do so with arbitrary or unknowable data, you run the risk of potentially catastrophic consequences that may logically last well beyond the lifetime of your program.

Within the scope of C++ as a language, this condition is summed up in a specific phrase: undefined behaviour. It states that you can't really rely on anything at all after you've corrupted your memory. Once you've invoked UB, all bets are off.

The one guarantee that you usually have in practice is that your OS will not allow you to directly overwrite any memory that does not belong to your program. That is, corrupting the memory of other processes or of the OS itself is very difficult. The memory model of modern OSs is deliberately designed that way in order to keep programs isolated and prevent this kind of damage from broken programs and/or viruses.