Can Valgrind mend memory corruption?

Question

I am testing a C++ program for problems. I am running it under valgrind.

I start the program with

     // valgrind test 
     char * p = (char*)malloc(4); 
     p[4] = 'A'; 
     free(p); 
     p[0] = 'A'; 

memcheck-amd64-linux reports these.

My question is:

Will valgrind protect the program so that this corruption does not screw up the heap?

The version is 3.11. The relevant options in effect are

                    " -demangle=yes" + /* Do not mangle names */ 
                    " --gen-suppressions=no" + // set to 'all' to generate 
                                                // suppressions 
                    " --suppressions=" + memcheckSupp + // ignore the errors 
                                                        // listed in that file 
                    " --leak-check=yes" + // Check for ML with details 
                    " --show-leak-kinds=definite" + // Report only definite ML 
                    " --errors-for-leak-kinds=definite" + // Only definite ML 
                                                            // are considered as 
                                                            // errors 
                    " --undef-value-errors=yes" + // UV detection 
                    " --track-origins=yes" + // Look for the origin of the UV 
                    " --keep-stacktraces=alloc-and-free" + // More info in case 
                                                            // of UAF 
                    " --show-mismatched-frees=yes" + // Detect free/malloc, 
                                                        // delete/new mismatch 
                    " --malloc-fill=0xAA" + // Put junk into newly allocated 
                                            // blocks 
                    " --free-fill=0xAA" +
                    " --frequency 100"

Answer 1

It usually takes more than only an invalid write just after heap memory or a write after free to corrupt the heap. In a lot of situations this will seem to "work". Memory tends to be allocated with 8 or 16 byte alignment, so writing one character too much often won't cause a crash. Similarly, writing to freed memory often doesn't cause a problem. The most common cause for heap corruption is a double free.

Often != always. Eventually the character overrun is going to hit unallocated memory and you'll get a SIGSEGV. Or the write to freed memory happens just after another thread has recycled that memory.

Sweeping errors under the carpet could also break things. Imagine (not a good idea) that someone writes code with a signal handler for SIGSEGV and deliberately provokes segmentation faults as part of the normal program flow. If Valgrind just printed an error and didn't perform the write, the signal would no longer be generated and the program behaviour would change.