Valgrind Lab                

Valhalla

Introduction                

This is a modified version of a valgrind tutorial from:

A video introduction is available.                 

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 situation. Why didn’t valgrind complain?                 

Add your one-line analysis 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 11:59ᴘᴍ MT Saturday, with a five-day late period.                 

How to receive negative points:                

Turn in someone else’s work.