Week 1 and 2 lab topics:

The topics of this week's lab are a review of C programming tools and utilities that you have used before and that you should use when solving lab 1.

1. man and apropos
2. make and makefiles
3. git revision control software
4. libraries in C (.h, .c, and linking .o files)
5. signals and signal handler functions
6. review of C debugging tools: gdb (and ddd) and valgrind

All the links to documentation are also available off my help pages

---

Start by creating a cs45 subdirectory in your home directory, and then create a weeklylabs/w01 subdirectory into which you will copy over some files:

  mkdir cs45
  cd cs45 
  pwd
  mkdir weelylabs
  cd weeklylabs
  mkdir w01 
  cd w01
  pwd
  cp ~newhall/public/cs45/week01/* .
  ls

Here is some information about how to read manual page using man and how to find commands and library functions using apropos: man and apropos

Try looking at the man page for fork to see how it is telling you information about the fork function: how to call it; what header file(s) to be included to call it; and what the function does and what its return value(s) are.

% man fork
# or, I could specify the man section...I don't need to for fork:
% man 2 fork   # the man page for the system call fork in section 2 of the manual

Here is some information about using make and makefiles to build executables: make and makefiles You will use a makefile in lab 1.

Here is some information about using library code in your programs and also about how to write and link a simple library of your own (use the .o version): libraries in C Your lab 1 solution will consist of at least two .c files with a .h file interface (one .c and the .h are a library you implement that the other .c file will use).

Here is some information on using git revision control software for projects with partners: using git

Let's look at the program signals.c. This program has some examples of registering a signal handler function on a signal, and of some examples of ways in which you can send signals to processes (for example, alarm can be used to send a SIGALRM to one's self).

We will try running this and use the kill command to send the process signals:

kill -INT 1234  # sends a SIGINT signal to process 1234

Let's try running the program and see what it is doing.

The man page for signal lists the signals on this system and describes the signal system call in more detail.

In the code you copied over are two subdirectories with test files for gdb and valgrind. We are going to go over just a couple of these, but see my gdb and valgrind documentation (both linked to below) for more information about using gdb and valgrind and try out some more examples.

Today, we are going to look at some features of gdb for debugging C programs. In particular, looking at a stack trace, moving between frames to examine parameter and argument values, and examining runtime state of a segfaulting program. Again, you can use ddd, but I'm going to show you the gdb commands running gdb.

Here is a directory of files you can copy over that can be used to test out some gdb features:

cd ~/cs45/weeklylabs
cp -r ~newhall/public/gdb_examples .
cd gdb_examples

First, run make to build the executables (note they are all compiled with -g).

Let's look through a couple of the example programs in gdb, following along in my GDB Guide.

We are going to look at badprog and segfaulter in gdb. These are listed in the "Sample gdb sessions" part of my gdb guide under run 1: debugging badprog and run 2: debugging segfaulter.

One example program that you may want to try out is the fork_example.c. It can be used to test out the gdb support for specify which process gdb should follow on a fork (either the parent XOR the child):

(gdb) set follow-fork-mode child    
(gdb) set follow-fork-mode parent   # gdb's default behavior

Up the page on this guide are lists of common gdb commands and some examples of how to use them.

cd into the valgrind_examples subdirectory.

Valgrind is a tool for finding heap memory access errors and memory leaks in C and C++ programs. Memory access errors are often very difficult bugs to find, and valgrind helps you easily find errors like reads or writes beyond the bounds of a malloc'ed array, accessing free'ed memory, reading uninitialized memory, and memory leaks (not freeing malloc'ed space before all variables referring to it go out of scope).

Here are some files you can copy over that can be used to test out valgrind:

cd ~/cs45/weeklylabs
cp -r ~newhall/public/valgrind_examples .
cd valgrind_examples

To use valgrind, just compile with -g, and run valgrind on your program (the Makefile has this already):

make
valgrind ./badprog

The output at first seems a bit cryptic, but once you see the basics of how to interpret it, it is extremely helpful for finding and fixing memory access errors. Let's look at my Valgrind Guide to see how to interpret some of this valgrind output. This guide contains links to other valgrind resources, and the README file in the code you copied over lists some command line options for running valgrind.

Some more information on debugging tools for C: C programming tools: gdb and valgrind