This lab will give you experience using both Valgrind’s code checking tools. Clone the repo down and proceed as usual.

You will need to create a file named to write responses in.

Problem 0: Clean up after yourself

You know the drill.

Create a .gitignore file and add stuff you want to ignore.

You will lose points…

  1. If you don’t have a .gitignore.
  2. If you commit compiled files, editor droppings, or other junk.

Problem 1: Drip, Drip, Drip, Drip

  1. Change into the Problem1 directory and take a look at the project. It’s a linked list similar to the problem from last time.
  2. Build it and run it in Valgrind. What is the problem?
  3. Why is this problem occurring? (What memory is being allocated, and what memory is being freed?)
  4. Fix the bug and check that your fix is correct.

Problem 2: Imagine the possibilities!

  1. Change into the Problem2 directory and take a look at the source files in the project.
  2. Without running the code: What section of the Leak Summary1 do you think Valgrind will report each block in?
  3. Build and run the code through Valgrind. Were you right? If not, how did things differ?

    • Ignore the compiler warnings.
  4. Why do you think there is a difference between the plain and dtor classes?

    • In other words, what are we trying to demonstrate by using a class that has a destructor and one that doesn’t?
    • Hint: Does having a destructor affect the way the program leaks?

Note that you don’t need to fix any code for Problem 2.

Problem 3: Copy cat… or is it?

  1. Change into the Problem3 directory and take a look at the source.
  2. Build the code and run it through Valgrind. What is the result?
  3. What is the problem?
  4. Fix the bug and check that your fix is correct.



You will be graded on:

  • The presence of a useful .gitignore and absence of junk files.
  • Your file.
    • Responses must be complete and coherent. Use complete sentences.
    • Make sure you’ve answered all questions in the assignment.
    • Your lines should not exceed 80 columns.
    • Feel free to use Markdown to format your file.
  • Your fixed project files in Problem1/.
    • Use proper C++ style.
    • We will test your code to ensure that it works as expected.
  • Your fixed project files in Problem3/.
    • Use proper C++ style.
    • We will test your code to ensure that it works as expected.


As always, your git repo on is your submission. Don’t forget to commit and push all relevant files. Make sure you see everything you expect on GitLab!

We expect to see the following files on your master branch:

  • .gitignore
  • examples/
    • .gitignore
    • Makefile
    • delete.cpp
    • invalid-stack.cpp
    • invalid.cpp
    • leak.cpp
    • reachable.cpp
    • uninitialized-value.cpp
    • use-after-free.cpp
  • Problem1/
    • Makefile
    • list.cpp
    • list.h
    • main.cpp
  • Problem2/
    • Makefile
    • dtor.h
    • main.cpp
    • plain.h
  • Problem3/
    • Makefile
    • main.cpp
    • vector.cpp
    • vector.h

Notice that your repository has subdirectories! You have the option to put one .gitignore file at the root of your repo, or individual .gitignore files in each subdirectory if you prefer.

  1. The Leak Summary has 5 sections: “definitely lost”, “indirectly lost”, “possibly lost”, “still reachable”, and “suppressed”.