Secure Systems Engineering, Fall 2024

Lab 1

• Out on: Wed Aug 28
• Due on: Tue Sep 3, 10p EDT
• Collaboration: groups of 2 (assigned in class)
• Grading: completion, out of 15 points
  • 5 points for the fixed buggy program
  • 5 points for the response comments for the second bug in buggy
  • 5 points for the response comments for the third bug in buggy

Please read this description in its entirety before starting the assignment!

Introduction

gdb is a debugger for C (and C++) and other languages. It allows you to do things like run the program up to a certain point then stop and print out the values of certain variables at that point, or step through the program one line at a time and print out the values of each variable after executing each line. It uses a command line interface.

Learning objectives

In this lab, you will:

• Explain the purpose and benefits of using a debugger
• Use GDB to examine program state during execution for debugging
• Document your debugging steps and findings effectively

Helpful resources

• If you’ve never used Git before, go through the GitHub Starter Course and its linked reading.
• As you learn gdb, you can use reference cards to help you remember the correct command invocations.

Assignment setup

Starter code

The starter code for this lab can be found on the lab’s Git repository. To clone it, enter the following command in your terminal:

$ git clone https://github.com/spacelab-ccny-teaching/sse-fall24-lab1.git

Using GDB

To prepare your program for debugging with gdb, you must compile it with the -g flag. So, if your program is in a source file called example.c and you want to put the executable in the file example, then you would compile with the following command:

$ gcc -g -o example example.c

To start gdb on a program example, just type in:

$ gdb example

gdb will give you a prompt that looks like this:

(gdb)

From that prompt you can run your program, look at variables, etc., using various commands. Quit gdb by typing in q.

Part 0: A guided overview

For today’s exercise, we will use the following commands:

$ gcc -g -std=c99 -w fixed.c -o fixed -lm

$ gcc -g -std=c99 -w buggy.c -o buggy -lm

• -w: suppresses the warnings
• -std=c99:  the std flag sets the C standard version, which we set to C99 (allowing for in-line for loops)
• -lm: to link to the math library when building the executable

There are three bugs in the code buggy.c. The program is meant to find the sum of the first 10 prime numbers. A prime number is a number that is only divisible by itself and 1 (excluding the number 1). For example: 2, 3, 5, 7, 11, etc. The program should output the result 129.

We will work on the first bug together in class using gdb. Be sure to pay attention, and take notes. Solving this first bug will help you solve the remaining two bugs.

Part 1: Debugging on your own

You will have to find the second and third bugs in buggy.c on your own. Each time you solve a bug, record answers to the following:

1. Where in the file you did you find the bug?
2. What GDB commands did you use to find it?
3. What is the root cause of the bug, i.e., why is this a bug?
4. What code did you use to solve the bug?

Put the answers for these questions at the top of buggy.c as a comment. You should have 8 total responses – 4 for each bug you fixed in buggy.c, outside of the one we did together in class.

The top of your final buggy.c code should look something like this:

/**
 * BUG1:
 * 1. (your answer here)
 * 2. (your answer here)
 * ...
 *
 * BUG2:
 * 1. (your answer here)
 * 2. (your answer here)
 * ...
 */

/**
 * This program computes the sum of the first n
 * prime numbers.  Optionally, it allows the user
 * to provide n as a command line argument, but
 * defaults to the first n = 10 primes
 */
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
...

What to turn in

Upload the following to Blackboard before the due date above:

• The gzipped code archive of your sse-fall24-lab1 project directory
  • The file buggy.c that has all three bugs fixed. Note that the buggy.c file should run correctly, i.e., the same as the fixed.c file.
  • The top of buggy.c should contain comments responding to the questions above. These may take up several lines.

Please reach out to the instructor (well in advance of the due date!) if you have questions about submission.