Bookmark this page

Guided Exercise: Debugging Memory Leaks

Identify memory leaks.

Outcomes

You should be able to use the valgrind framework to identify a virtual memory leak and a resident memory leak.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

[student@workstation ~]$ lab start application-memory

This command installs the bigmem application that causes a memory leak.

Instructions

The bigmem application in this exercise causes a memory leak. To verify the memory leak, run the bigmem application with the memcheck tool in the valgrind framework.

  1. Log in to servera and switch to the root user.

    [student@workstation ~]$ ssh student@servera
    ...output omitted...
    [student@servera ~]$ sudo -i
    [sudo] password for student: student
    [root@servera ~]#
  2. Install the valgrind package on the servera system.

    [root@servera ~]# yum install valgrind
    ...output omitted...
    Complete!
  3. Use the valgrind tool to run the bigmem command, allocating 256 MiB of physical memory.

    The valgrind summary indicates a memory leak.

    [root@servera ~]# valgrind --tool=memcheck bigmem 256
    ==26907== Memcheck, a memory error detector
    ==26907== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
    ==26907== Using Valgrind-3.16.0 and LibVEX; rerun with -h for copyright info
    ==26907== Command: bigmem 256
    ==26907==
    Attempting to allocate 256 Mebibytes of resident memory...
    Press <Enter> to exit Enter
    ==26907==
    ==26907== HEAP SUMMARY:
    ==26907==     in use at exit: 268,435,456 bytes in 256 blocks
    ==26907==   total heap usage: 258 allocs, 2 frees, 268,437,504 bytes allocated
    ==26907==
    ==26907== LEAK SUMMARY:
    ==26907==    definitely lost: 263,192,576 bytes in 251 blocks
    ==26907==    indirectly lost: 0 bytes in 0 blocks
    ==26907==      possibly lost: 5,242,880 bytes in 5 blocks
    ==26907==    still reachable: 0 bytes in 0 blocks
    ==26907==         suppressed: 0 bytes in 0 blocks
    ==26907== Rerun with --leak-check=full to see details of leaked memory
    ==26907==
    ==26907== For lists of detected and suppressed errors, rerun with: -s
    ==26907== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
  4. Use valgrind to run the bigmem application again, with 256 MiB of virtual memory.

    The summary output matches the output for physical memory.

    [root@servera ~]# valgrind --tool=memcheck bigmem -v 256
    ==26910== Memcheck, a memory error detector
    ==26910== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
    ==26910== Using Valgrind-3.16.0 and LibVEX; rerun with -h for copyright info
    ==26910== Command: bigmem -v 256
    ==26910==
    Attempting to allocate 256 MebiBytes of virtual memory...
    Press <Enter> to exit Enter
    ==26910==
    ==26910== HEAP SUMMARY:
    ==26910==     in use at exit: 268,435,456 bytes in 256 blocks
    ==26910==   total heap usage: 258 allocs, 2 frees, 268,437,504 bytes allocated
    ==26910==
    ==26910== LEAK SUMMARY:
    ==26910==    definitely lost: 264,241,152 bytes in 252 blocks
    ==26910==    indirectly lost: 0 bytes in 0 blocks
    ==26910==      possibly lost: 4,194,304 bytes in 4 blocks
    ==26910==    still reachable: 0 bytes in 0 blocks
    ==26910==         suppressed: 0 bytes in 0 blocks
    ==26910== Rerun with --leak-check=full to see details of leaked memory
    ==26910==
    ==26910== For lists of detected and suppressed errors, rerun with: -s
    ==26910== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
  5. The valgrind command detected the memory leak but provides insufficient information to know the type of memory leak from the bigmem application.

    1. In a second terminal, log in to the servera system and switch to the root user.

      [student@workstation ~]$ ssh student@servera
      ...output omitted...
      [student@servera ~]$ sudo -i
      [sudo] password for student: student
    2. Continuously display an overview of the system's allocated and committed memory.

      [root@servera ~]# watch -d -n1 'free -m; grep -i commit /proc/meminfo'
    3. In the first terminal window, run the bigmem application twice to allocate physical memory and virtual memory. This time, do not use the valgrind tool. Before you press Enter for both of the commands, navigate to the terminal running the watch command and verify the output.

      [root@servera ~]# bigmem 256
      Attempting to allocate 256 Mebibytes of resident memory...
      Press <Enter> to exit
      [root@servera ~]# bigmem -v 256
      Attempting to allocate 256 Mebibytes of virtual memory...
      Press <Enter> to exit
    4. View the system's allocated and committed memory in the second terminal.

      The watch command output shows the bigmem application using the requested memory when run without the -v option. In this case, both committed memory (Committed_As field) and resident memory (used column) rise by the requested amount of memory.

      When run with the -v option, the committed memory (Committed_As field) increases with the requested amount, but resident memory (used column) does not increase significantly. The resident memory (used column) increase slightly due to memory for executing itself and its page tables.

    5. Use Ctrl+C to exit the watch command in the second terminal.

  6. Exit the second terminal.

    [root@servera ~]# exit
    [student@servera ~]$ exit
    [student@workstation ~]$ exit

    Return to the workstation machine as the student user on first terminal.

    [root@servera ~]# exit
    [student@servera ~]$ exit
    [student@workstation ~]$

Finish

On the workstation machine, use the lab command to complete this exercise. This is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish application-memory

Revision: rh342-8.4-6dd89bd