UC3M

One type of problems detected is warning about the code that it is reading/writing illegal positions from a program. Let's look at an example that consists of an illegal writing on the zero memory position. This illegal access is performed by writing a memory address that is not in the program and releasing the alarm Memcheck:

1
2
3
4
5
6
7
8
9
10

// Illegal write
// gcc -gstabs valgrind_illegal_write.c -o valgrind_illegal_write
// $ valgrind  -v ./valgrind_illegal_write 
#include <stdlib.h>
int main()
{
  int *ptr=0;
  (*ptr)=33;
  return 0;
} 

Let's see how Valgrind reports (with a illegal write) about this issue in the main function:

$ gcc -gstabs -Wall valgrind_illegal_read_write.c -o valgrind_illegal_read_write
$ valgrind -v ./valgrind_illegal_read_write 
  
--6429--   .. CRC is valid
--6429-- REDIR: 0x40d01e0 (strnlen) redirected to 0x40254a0 (_vgnU_ifunc_wrapper)
--6429-- REDIR: 0x40d1730 (strncasecmp) redirected to 0x40254a0 (_vgnU_ifunc_wrapper)
--6429-- REDIR: 0x40d0380 (__GI_strrchr) redirected to 0x402c1b0 (__GI_strrchr)
==6429== Invalid write of size 4
==6429==    at 0x80483C4: main (valgrind_illegal_read_write.c:8)
==6429==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==6429== 
==6429== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Another type of issue that Valgrind detects is uninitialised variables. To illustrate this issue , the following listing contains a variable: number which has not been properly initialised.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// Unitialized
// gcc -gstabs valgrind_illegal_write.c -o valgrind_illegal_write
// $ valgrind  -v ./valgrind_illegal_write 
#include <stdlib.h>
#include <stdio.h>
int main()
{
  int number; //Should be initialized (i.e. to zero).
  if (number==0)
  {
    printf("number is zero");
  }
    
  return 0;
} 

This is how Memcheck reports on this error:

$ gcc -gstabs -Wall valgrind_unitialized.c -o valgrind_unitialized
$ valgrind -v --track-origins=yes ./valgrind_unitialized

==6684== 
==6684== 1 errors in context 1 of 1:
==6684== Conditional jump or move depends on uninitialised value(s)
==6684==    at 0x80483F2: main (valgrind_unitialized.c:9)
==6684==  Uninitialised value was created by a stack allocation
==6684==    at 0x80483EA: main (valgrind_unitialized.c:7)
==6684== 
==6684== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Another issue checked by Memcheck is illegal uses of free statement.

1
2
3
4
5
6
7
8
9
10
11
12
13

// illegal free
// gcc -gstabs valgrind_illegal_free.c -o valgrind_illegal_free
// $ valgrind  -v ./valgrind_illegal_free 
#include <stdlib.h>
#include <stdio.h>
int main()
{
  int * ptr=malloc(4);
  free(ptr);
  ptr++; //To mismatch 
  free(ptr);  
  return 0;
} 

In this case, the free statement is peformed on a memory position which has not been allocated with malloc, being the root of the problem.

$ gcc -gstabs -Wall valgrind_illegal_free.c -o valgrind_illegal_free
$ valgrind -v --track-origins=yes ./valgrind_illegal_free
==12950== Memcheck, a memory error detector
==12950== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==12950== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==12950== Command: ./valgrind_illegal_free
==12950== 
==12950== Invalid free() / delete / delete[] / realloc()
==12950==    at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==12950==    by 0x8048449: main (valgrind_illegal_free.c:11)
==12950==  Address 0x41fd02c is 0 bytes after a block of size 4 free'd
==12950==    at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==12950==    by 0x8048438: main (valgrind_illegal_free.c:9)
==12950== 
==12950== 
==12950== HEAP SUMMARY:
==12950==     in use at exit: 0 bytes in 0 blocks
==12950==   total heap usage: 1 allocs, 2 frees, 4 bytes allocated
==12950== 
==12950== All heap blocks were freed -- no leaks are possible
==12950== 
==12950== For counts of detected and suppressed errors, rerun with: -v
==12950== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Lastly, there is a functionality in charge of detecting memory leaks, which is one of the most interesting features of valgrind. The following listing include an example which has a function leak that performs a memory leak of 100 bytes, per invocation.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// memory_leak
// gcc -gstabs valgrind_memory_leak.c -o valgrind_memory_leak
// $ valgrind  -v ./valgrind_memory_leak
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

void leak()
{  
  void *ptr=malloc(100);
  ptr++;
}
int main()
{
  printf("#Let's leak 100 bytes");
  leak();
  printf("#100 bytes leaked");
  return 0;
} 

This the trace of Valgrind, which corresponds to the previous listing, which shows how to Memcheck warns about this issue:

$ gcc -g -Wall valgrind_memory_leak.c -o valgrind_memory_leak
$ valgrind -v --leak-check=full --show-reachable=yes  ./valgrind_memory_leak
    
--7436-- REDIR: 0x40cbe70 (malloc) redirected to 0x402be00 (malloc)
Let's leak 100 bytes100 bytes leaked==7436== 
==7436== HEAP SUMMARY:
==7436==     in use at exit: 100 bytes in 1 blocks
==7436==   total heap usage: 1 allocs, 0 frees, 100 bytes allocated
==7436== 
==7436== Searching for pointers to 1 not-freed blocks
==7436== Checked 55,964 bytes
==7436== 
==7436== 100 bytes in 1 blocks are definitely lost in loss record 1 of 1
==7436==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==7436==    by 0x8048425: leak (valgrind_memory_leak.c:10)
==7436==    by 0x8048445: main (valgrind_memory_leak.c:16)
==7436== 
==7436== LEAK SUMMARY:
==7436==    definitely lost: 100 bytes in 1 blocks
==7436==    indirectly lost: 0 bytes in 0 blocks
==7436==      possibly lost: 0 bytes in 0 blocks
==7436==    still reachable: 0 bytes in 0 blocks
==7436==         suppressed: 0 bytes in 0 blocks
==7436== 
==7436== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==7436== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)