Valgrind Lab
Credits
This is a modified version of a valgrind tutorial from:
The Hebrew University
Rachel & Selim Benin
School of Computer Science & Engineering
Name
Contrary to popular belief, the name refers to one of the gates of
Valhalla. The tool was going to be named Heimdall, after the
all-seeing Norse god, but somebody else had the name already.
Purpose of this Lab
You will create a file results.txt, and turn it in for credit.
It will have this format, with a blank line between entries:
exp1: delete[] not called
exp2: explanation of the problem with exp2.cc
exp3: explanation of the problem with exp2.cc
…
exp10: explanation of the problem with exp10.cc
This lab demonstrates use of valgrind, a tool that helps you find memory
leaks, uninitialized variables, and bad memory accesses in your
programs.
To accomplish this, we use a number of example programs. These are
trivial programs, for teaching purposes, so you will probably be able to
just glance at the programs and find the problems without using
valgrind. However, imagine a ten thousand line program with dozens of
conditional memory allocations and deallocations—that might be a bit
more difficult.
Files
This tutorial uses a number of source files. Get them from the web at
~cs253/Lab/Valgrind
or copy them to the current directory with:
cp ~cs253/Lab/Valgrind/*.cc .
if you’re running on a CS Dept. computer.
Example #1
Consider the first program, exp1.cc. Examine it with cat exp1.cc.
If you see a problem with it, do not shout it out—it’s not a contest:
int main() {
[[maybe_unused]] char *x = new char[100];
return 0;
}
Compile the first program (my shell prompt is “%”):
% g++ -Wall exp1.cc
Run it. All appears well:
% ./a.out
Run it again with valgrind:
% valgrind ./a.out
Amongst all that, you see the distressing message
definitely lost: 100 bytes in 1 blocks
and the instruction
Rerun with --leak-check=full to see details of leaked memory.
Do so:
% valgrind --leak-check=full ./a.out
That’s still quite noisy; use the -q (quiet) option:
% valgrind -q --leak-check=full ./a.out
That last line isn’t very helpful. Recompile with -g (debug
information) so that valgrind can pinpoint which line allocated the
leaked memory, and re-run valgrind:
% g++ -Wall -g exp1.cc
% valgrind -q --leak-check=full ./a.out
The problem, of course, is that 100 bytes were allocated, but never
deallocated. Add code to exp1.cc to deallocate the memory,
recompile and run with valgrind to show that the memory is now properly
deallocated.
Add “exp1: delete[ ] not called” to results.txt.
Example #2
Compile and run exp2.cc:
% g++ -Wall -g exp2.cc
% ./a.out
It seems to run just fine, but the code is clearly flawed. What’s the
problem? Why didn’t you get a segmentation fault?
Now, run it with valgrind:
% valgrind -q --leak-check=full ./a.out
Read and understand the messages.
Write down, in results.txt, what was causing the problem.
Make sure to start the line with “exp2: ”.
Examples #3–8
Compile and run exp3.cc through exp8.cc with valgrind, and
understand the problems. For each one, add your one-line analysis of
the problem to results.txt.
Example #9
Compile and run exp9.cc, with valgrind, and understand the problem.
When you run the program without valgrind, the memory allocation
library is smart enough to detect that something bad has occurred.
However, valgrind’s error message is much better than the message
without valgrind.
Add your one-line analysis of the problem to results.txt.
Example #10
Compile and run exp10.cc, with valgrind, and understand the
problem. Looks like valgrind can’t find all problems!
Add your one-line analysis of the problem to results.txt.
For Extra Fame & Glory (but no points)
Modify exp9.cc so that the memory allocation library doesn’t detect the
problem, but that valgrind does. If you manage this, let me know what
you did!
How to submit your work:
In Canvas, check in the
file
results.txt to the assignment “Lab07”.
It’s due 10:00:00ᴘᴍ MT Saturday, with a 24-hour late period for a 25% penalty.
How to receive negative points:
Turn in someone else’s work.