CSE 333 26su

Section 2

Debugging and Structs

Checking In & Logistics

• Exercise 2:
• Due Today @ 11:59 PM
• Reminder: put exercise directories (e.g. ex2) directly in the root
• Homework 1:
• Due July 9 by 11:59 pm
• You hopefully have started it by now!
• Any questions, comments, or concerns?
• Exercises going ok?
• Lectures making sense?

2

Debugging Tools

3

Debugging

• ✨ Debugging is a skill that you will need throughout your career! ✨
• The 333 projects are big with lots of potential for bugs
• Learning to use the debugging tools will make your life a lot easier
• Course staff will help you learn the tools in office hours, too
• Debugging tool output can be scary at first, but extremely useful once you know how to parse it

4

Debugging Strategies

Many debugging strategies exist but here’s a simple 4 step process!

5

1. Observation: What is the difference between the expected and actual behavior?

e.g., Expected NumElements(llp) to be 3, actually 627147133

2. Hypothesis: What do you think is going wrong?

3. Experiment: Use debuggers and other tools to verify the problem

4. Analyze: Identify and implement a fix to the problem.

Key Debugging Skills to Master

1. Set breakpoints to stop at “interesting” places
• e.g., start or end of functions, right before a crash or segfault, before/after key variables are changed
2. Inspect program state – ask questions and answer them with the debugger
• Print values of variables, memory, and other expressions of interest
• Look at source code
• Look up/down call chain
3. Resume execution
• Incrementally, step at a time
• Until next breakpoint
• Until finished

6

333 Debugging Options

• gdb (GNU Debugger) is a general-purpose debugging tool
• Stops at breakpoints and program crashes
• Lots of helpful features for tracing code, checking current expression values, and examining memory
• valgrind specifically check for memory errors
• Great for catching non-crashing odd behavior (e.g., using uninitialized values, memory leaks on the heap)
• If your code uses malloc, should use --leak-check=full option

7

Basic Functions in GDB

• Setting breakpoints:
• break <filename>:<line#>
• Advancing
• step – into functions
• next – over functions
• continue – to next break

• Reading Values
• print – evaluate expression once
• display – keep evaluating expression
• Examining memory
• x – dereference provided address
• bt – backtracing

​

8

• Reference Card:�https://courses.cs.washington.edu/courses/cse333/26sp/debug/gdb_refcard.pdf

​

Common Errors

• Misusing Functions: Read documentation (online, through man pages, or the .h files for your homework) for function parameters and function purpose
• Oftentimes, this leads to unexpected results!

​

• Segmentation Fault: Dereferencing an uninitialized pointer, NULL, a previously-freed pointer, or many other things.
• GDB automatically halts execution when SIGSEGV is received, useful for debugging

​

• Memory “Errors”: Many possible errors, commonly use of uninitialized memory or “memory leaks” (data allocated on heap that does not get free’d).
• Use valgrind to help catch memory errors!

9

Debugging Example: reverse.c

10

Trying to Run reverse.c

We have a program reverse.c that accepts a string from the user and reverses it, but it has a few problems… let’s take a look!

11

char * Reverse(char * s) {

char * result = NULL; /* the reversed string */

int left_i, right_i;

char ch;

​

strcpy(result, s);

​

left_i = 0;

right_i = strlen(result);

while (left_i < right_i) {

ch = result[left_i];

result[left_i] = result[right_i];

result[right_i] = ch;

++left_i; --right_i;

}

​

return result;

}

Structs and Typedef Review

12

Defining Structs

• To define a struct, we use the struct statement, which typically has a name (a tag) and must have one or more data members
• This defines a new data type!

13

struct simplestring_st {

char* word;

int length;

};

struct simplestring_st my_word;

Typedef

• The C Programming language provides the keyword typedef, which defines an alias (alternate name) for an existing data type
• This can be used in combination with a struct statement

14

struct simplestring_st {

char* word;

int length;

};

typedef struct simplestring_st SimpleString;

SimpleString my_word;

typedef struct simplestring_st {

char* word;

int length;

} SimpleString;

SimpleString my_word;

Structs and Memory Diagrams

• struct instance is a box, with individual boxes for fields inside of it, labelled with field names
• Even though we know that field ordering is guaranteed, we can be loose with where we place the fields in our diagram

15

typedef struct simplestring_st {

char* word;

int length;

} SimpleString;

SimpleString my_word;

Structs and Pointers

​

• “.” to access field from struct instance
• “->” to access field from struct pointer

​

16

char cse333[] = "cse333";

SimpleString cse333_ss;

SimpleString* cse333_ptr = &cse333_ss;

​

cse333_ss.word = cse333;

cse333_ptr->length = strlen(cse333);

cse333

typedef struct simplestring_st {

char* word;

int length;

} SimpleString;

Passing Structs as Parameters

• Structs are call-by-value (as arguments and return values)
• Can imitate call-by-reference by passing pointer to struct instance instead
• Assignment copies over all of the field values – be very careful with pointers!

17

SimpleString new_ss = cse333_ss;

cse333

Aside: HW1 Diagrams and Connection

• HW1 makes extensive use of structs
• Many bugs from misunderstanding memory
• Draw out example/test memory diagrams and use existing ones!

18

Debugging Exercise

19

Debugging Exercise – simplestring.c

The code for simplestring.c is on your worksheet!

• Uses helper function InitWord() to set values in a SimpleString to �(1) "computer", then (2) "cse333".
• Draw a memory diagram
• Debug behavior
• Fix style

20

21

Production Debugging 101: Logging vs. Monitoring vs. Tracing

Think of a production system like a hospital

Extra readings:�

• Distributed tracing.
• How to think while debugging.
• Quality vs velocity to avoid debugging.

Debugging Strategies

Many debugging strategies exist but here’s a simple 4 step process!

1. Observation: What is the difference between the expected and actual behavior?
• e.g., Expected NumElements(llp) to be 3, actually 627147133
2. Hypothesis: What do you think is going wrong?
3. Experiment: Use debuggers and other tools to verify the problem
4. Analyze: Identify and implement a fix to the problem.
5. Repeat steps 1-4 until bug free!

22