Sources of uninitialized data are:

This is not a problem with calloc since it initializes each allocated bytes with 0. The new operator in C++ is similar to malloc. Fields of the created object will be uninitialized.

Sample program:

#include <stdlib.h>
int main()
{
	int p, t;
	if (p == 5)             /*Error occurs here*/
		t = p+1;
	return 0;
}

Here the value of p is uninitialized, therefore p may contain some random value (garbage), so an error may occur at the condition check. An uninitialized variable will cause error in 2 situations:

Illegal read/write errors occurs when you try to read/write from/to an address that is not in the address range of your program.

Sample program:

#include <stdlib.h>
int main()
{
        int *p, i, a;
        p = malloc(10*sizeof(int));
        p[11] = 1;                /* invalid write error */
        a = p[11];                /* invalid read error */
                free(p);
        return 0;
}

Here you are trying to read/write from/to address (p+sizeof(int)*11) which is not allocated to the program.

Valgrind keeps track of blocks allocated to your program with malloc/new. So it can easily check whether argument to free/delete is valid or not.

Sample program:

#include <stdlib.h>
int main()
{
        int *p, i;
        p = malloc(10*sizeof(int));
        for(i = 0;i < 10;i++)
                p[i] = i;
        free(p);
        free(p);        /* Error: p has already been freed */
        return 0;
}

Valgrind checks the address, which is given as argument to free. If it is an address that has already been freed you will be told that the free is invalid.

In C++ you can allocate and free memory using more than one function, but the following rules must be followed:

Sample program:

#include <stdlib.h>
int main()
{
        int *p, i;
        p = ( int* ) malloc(10*sizeof(int));
        for(i = 0;i < 10;i++)
                p[i] = i;
        delete(p);                /* Error: function mismatch */
        return 0;
}

Output by valgrind is:

             ==1066== ERROR SUMMARY: 1 errors from 1 contexts (suppressed:
0 from 0)
             ==1066== malloc/free: in use at exit: 0 bytes in 0 blocks.
             ==1066== malloc/free: 1 allocs, 1 frees, 40 bytes allocated.
             ==1066== For a detailed leak analysis,  rerun with:
--leak-check=yes
             ==1066== For counts of detected errors, rerun with: -v

>From the above “ERROR SUMMARY” it is clear that there is 0 bytes in 0 blocks in use at exit, which means that the malloc'd have been freed by delete. Therefore this is not a problem in Linux, but this program may crash on some other platform.

Valgrind checks all parameters to system calls.

Sample program:

#include <stdlib.h>
#include <unistd.h>
int main()
{
        int *p;
        p = malloc(10);
        read(0, p, 100);        /* Error: unaddressable bytes */
        free(p);
        return 0;
}

             ==1045== Syscall param read(buf) contains unaddressable
byte(s)
             ==1045==    at 0x4032AF44: __libc_read (in
/lib/i686/libc-2.2.2.so)
             ==1045==    by 0x4026D177: __libc_start_main
(../sysdeps/generic/libc-start.c:129)
             ==1045==    by 0x80483E1: read@@GLIBC_2.0 (in
/home/deepu/valg/a.out)

Here, buf = p contains the address of a 10 byte block. The read system call tries to read 100 bytes from standard input and place it at p. But the bytes after the first 10 are unaddressable.

Consider the following program:

#include <stdlib.h>
int main()
{
        int *p, i;
        p = malloc(5*sizeof(int));
        for(i = 0;i < 5;i++)
                p[i] = i;
        return 0;
}

             ==1048== LEAK SUMMARY:
             ==1048==    definitely lost: 20 bytes in 1 blocks.
             ==1048==    possibly lost:   0 bytes in 0 blocks.
             ==1048==    still reachable: 0 bytes in 0 blocks.

In the above program p contains the address of a 20-byte block. But it is not freed anywhere in the program. So the pointer to this 20 byte block is lost forever. This is known as memory leaking. We can get the leak summary by using the Valgrind option --leak-check=yes.