March 5, 2019
For today:
1) Read Think OS Chapter 6 and do the reading quiz
2) Start Homework 5
3) Work on your project
Today:
1) Homework 5
2) Memory management
3) Valgrind
4) Practice quiz and shapes.c
5) Project meetings
For next time:
1) Read HFC Chapter 6
2) Finish Homework 5
3) Prepare for a quiz (Here's the quiz from last year as practice).
I might ask a question that builds on the shapes.c framework (see Lecture 11 and the exercise below).
Floating-point representation: from scientific notation to IEEE 754
Representable floating point numbers are not uniformly spaced.
So how do we generate random floating point values?
In the homework, you'll extend this to 64 bits.
For the second part, you should pull from upstream to get an updated version of the starter code in find_track_oo.c.
Think OS Chapter 6
Know the malloc API (malloc, calloc, free, and realloc) and the performance you should expect from each.
The malloc API has the same disciplinary philosophy as Jasper Beardley:
Know what's a paddling:
If you access any chunk that has not been allocated, that’s a paddling.
If you free an allocated chunk and then access it, that’s a paddling.
If you try to free a chunk that has not been allocated, that’s a paddling.
If you free the same chunk more than once, that’s a paddling.
If you call realloc with a chunk that was not allocated, or was allocated and then freed, oh, you better believe that’s a paddling.
Know what goes wrong if you do one of these things:
1) Reading unallocated memory MIGHT seg-fault. Or it could yield arbitrary values, including values from other parts of the program. But they might be cross-interpreted (like reading a float as an int).
2) Writing to unallocated memory MIGHT seg-fault. Or it might clobber data from other parts of the program, causing unexpected values at some unpredictable point in the future. OR it might clobber malloc's internal data structures, causing unpredictable errors next time you malloc or free.
HINT: If malloc seg-faults, do not send a bug report to Doug Lea. But do read his paper.
What happens if a process leaks memory?
1) If the process runs for a short time and quits, leaking memory might be ok.
2) Otherwise, you might actually run out of physical memory.
3) Or you might cause other processes to get swapped out.
4) Or your own pages might get swapped out (which can be ok).
5) But often the system will start thrashing.
More about thrashing in Chapter 7. Or read about it now.
Principles of API design
1) Think object-oriented: each data type should have a constructor and destructor. If there's a make_blah, there should be a free_blah. Client code should not deallocate parts of an object made by a library.
2) Memory management requirements should be part of the documented interface.
3) If you didn't call malloc, you shouldn't call free (I'm looking at you, strdup).
Valgrind Exercise:
0) Install Valgrind and Valkyrie
sudo apt-get install valgrind valkyrie
Or on a Mac
brew install valgrind
But it might not work on current Macs.
1) Read the Valgrind quick start guide
2) cd into ExercisesInC/exercises/ex06 and compile mem_errors.c with debug info
gcc -g -Wall mem_errors.c
Then run it
./a.out
Then run Valgrind
valgrind --leak-check=yes ./a.out
Or use Valkyrie
valkyrie ./a.out
Read the errors messages and see how they relate to the errors in mem_error.c
3) Comment out or fix the errors and test until Valgrind runs cleanly.
1) If you have not done the shapes exercise from Lecture 11, do that.
2) Do the lines.c exercise from the practice quiz.