Tools for debugging

• We took a look at CS50 IDE, a new web-based programming environment. We learned to use:
  • check50 to check our work automatically
  • debug50 and the debugger to step through our code
  • help50 to make compilation errors more understandable
  • printf to print out helpful information as our program runs
  • style50 to check the style of our code
• We also looked at how memory is used by our programs in C, and how we can allocate and free memory.

[valgrind](<https://web.archive.org/web/20190905022323/https://cs50.harvard.edu/college/2018/fall/weeks/4/notes/#valgrind>)

• valgrind is a command-line tool that we can use to run our program and see if it has any memory leaks.

  • Recall that a memory leak happens when we call malloc to ask the operating system for memory for our program, but we don’t call free to mark it as free. Then, our program will use more and more memory as it runs, eventually slowing down or even crashing our entire computer.

• Let’s write a program called memory.c to experiment a little bit:

  #include <stdlib.h>
  
  void f(void)
  {
      int *x = malloc(10 * sizeof(int));
      x[10] = 0;
  }
  
  int main(void)
  {
      f();
      return 0;
  }
  

  • We have a function, f, that allocates memory for 10 integers, and using x as a pointer to the address of the start of that memory. Then, we try to access the 11th integer with x[10] (remember that pointers can act like arrays, since the memory we get is contiguous, or back-to-back).
  • When we run this program, we can see that it still works. It turns out, malloc sometimes (but not always) gives us back a little more memory than we ask for, and we might get lucky and be able to access and use memory beyond the bounds of what we should have.

• We can run our program with valgrind ./memory, and we see a lot printed out. But we do see one error message in particular, Invalid read of size 4, followed by some pointers in hexadecimal. We see f (memory.c:15) in the line immediately after, which tells us that this happened in line 15 of memory.c in the function f.

• We can also use help50 valgrind ./memory, which will distill the output for us, one error message at a time, and add additional clues to guide us.

• If we fix our program to access x[9], then valgrind onluy has 1 error message for us: 40 bytes in 1 blocks are definitely lost.... And help50 tells us that we forgot to free memory we allocated with malloc, so we should call free(x) after we’re doing using it. Now, we have 0 errors.

• Recall that we have some finite number of bytes in memory, and our operating system keeps track of which bytes are used by which program, which bytes are free, and indicates segmentation faults when we try to access memory that isn’t allocated to our program.

Rubber duck debugging

• Rubber duck debugging is the process of explaining our code, step-by-step, to a rubber duck (or some other inanimate object), so we ourselves can understand it better and hopefully realize where we might have a bug or opportunity of improvement. Hopefully, this will be another simple, but powerful, tool for us to use.

• 最简单的办法：从头到尾说一遍；说的过程意识到犯错误

• good software：脑海里出现过一次

  • fits in your head

More from last week

• We learned, last week, that a string is a synonym for char *, a pointer to a character.
• We also learned that memory is laid out in a certain way for our program, where different regions are used to store different types of data, such as:
  • the text segment, where the machine code for our program is loaded when we start it
  • the heap, where dynamically allocated memory (memory we allocate when the program is running), stores
  • the stack, where local variables and functions, including our main function, live when our program is running
• We saw a swap function that didn’t work, when values were passed in directly, since it got its own copies of those values. Then, we saw a swap function that took in the addresses of two variables, so those values could actually be swapped.
• Binky, from the short clip we saw, also demonstrated how we could dereference pointers and use them correctly (and incorrectly). We need to make sure that our pointers have a valid address, before we try to dereference them.
• Finally, we saw an introduction to structs, where we can build our own data structures, with variables of our choice.