Introduction

This lab will give you experience using gdb to debug programs. Clone your lab repository, then make a solutions file named answers.md to write your answers in.

Problem 0: Clean up after yourself

Create and commit a .gitignore file that ignores all compiled files and other crud. These items include, but are not limited to:

  • Editor backup file (e.g., ~ files, .bak files, and .swp files)
  • Compiled executables (e.g., a.out)
  • Object files (e.g., .o files)

You will lose points if you leave junk in your submission on GitLab. Remember that you can remove files that you previously committed using git rm.

Problem 1: Segfaults

  1. Change into the project directory. Use make to compile the code. Now run it. You should get a segfault.
  2. Open your executable in gdb and run it.
  3. Check the backtrace. What function is the segfault in?
  4. Check that function (you can print out bits of code using the list command; try list class::function_name).
  5. Set a breakpoint before the segfault, then run your code again and step through it.
  6. As you are stepping through, inspect the value of l.
  7. What is the bug in the code? Fix it.
  8. Run your code and make sure you have fixed the segfault. You should have another problem now…

Problem 2: Loopy

  1. At this point, you should have an infinite loop.
  2. Run the program, then press Ctrl-C to halt execution.
  3. Check the backtrace. What function is the infinite loop in?
  4. Put a breakpoint on the loop, then restart the program.
  5. run the code a few times and print the value of iter. What is happening to the addresses in the linked list?
  6. Fix the code. (Hint: List has a correct copy constructor, but it isn’t used…)
  7. Run the fixed code. Hopefully it should terminate, but…

Problem 3: Math is hard

  1. The sum is incorrect. Set a breakpoint that lets you watch what the sum function is doing.
  2. Inspect the local variables to see what is going on. What seems to be the problem?
  3. Fix the code. Run it to make sure your fix worked.

Problem 4: What do you think?

Write a paragraph or two about your experience with gdb. What did you like? What didn’t you like? What other features would be useful for a debugger1?

Epilogue

Grading

You will be graded on:

  • Your answers.md 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 project/.
    • Use proper C++ style.
    • We will test your code to ensure that it works.

Submissions

As always, your git repo on http://git-classes.mst.edu 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
  • answers.md
  • README.md
  • examples/
    • Makefile
    • combination.cpp
    • loop.cpp
    • segfault.cpp
  • project
    • Makefile
    • list.cpp
    • list.h
    • main.cpp

Notice that your repository has subdirectories! You have the option to put .gitignore files in the subdirectories if you prefer. Just make sure you’re not committing junk files.

  1. Note that gdb has more features that we covered. This question is asking you what features would be useful to you as a programmer, regardless whether gdb can do it or not.