12. Malloc

SoftSys Lecture Notes, Wednesday 3/17/21 #

SoftSys and Speedruns #

Project Update #

The project update assignment is basically a draft of the final report. Think of it as scaffolding for your final report.

Telling the story before you’re done can help you figure out what’s missing and plan out the rest of your work.

The project deadline will be extended by a week, to Wednesday 4/7.

The current proposal for the project update (currently due Monday 3/22) is to extend the deadline by one week, to Monday 3/29. If you want to submit your update earlier and get feedback, we can do that.

The changes to this week’s classes and the project deadline may also affect future readings, quizzes, homework, and Project 2.

I’m happy to consider shortening/eliminating any of these as needed. Today’s class is optional, so we’ll discuss this Monday, but please think about what you’d prefer for your learning.

malloc #

https://www.youtube.com/watch?v=ZXQR-cPXlmY

As mentioned in Think OS, the malloc API is rather unforgiving.

Don’t:

  • Use memory that hasn’t been allocated yet. (Remember pointers?)
  • Use memory that’s already been freed.
  • Free memory that hasn’t been allocated yet.
  • Free the same chunk of memory more than once.
  • Reallocate memory that hasn’t been allocated or that has already been freed.

It can be surprisingly hard to keep these rules in large software.

Exercise #

  1. Install valgrind: sudo apt install valgrind (or on macOS, brew install valgrind)
  2. Run it on a program like this: valgrind --leak-check=full ./a.out. Some options are (1) mem_errors.c in ex06 of the course repository, (2) files from previous homework assignments, or (3) programs installed on your machine (command line utilities, etc). Note that valgrind runs programs much more slowly.
  3. Report any highlights below. (Here’s a quick start guide for Valgrind if that’s helpful.)

As far as I can tell, git doesn’t have any memory leaks.

Valgrind’s memory leak messages let you know about different types of memory leaks:

  1. Definitely lost
  2. Indirectly lost
  3. Possibly lost
  4. Still reachable
  5. Suppressed

Here’s a (slightly lengthy) explanation of the above memory leaks.

Running a few test commands in Python in Valgrind:

==1674916== LEAK SUMMARY:
==1674916==    definitely lost: 0 bytes in 0 blocks
==1674916==    indirectly lost: 0 bytes in 0 blocks
==1674916==      possibly lost: 4,232 bytes in 8 blocks
==1674916==    still reachable: 891,512 bytes in 6,825 blocks
==1674916==         suppressed: 0 bytes in 0 blocks

Valgrind works by creating a synthetic CPU to run the executable.

Found memory leak in git pull.

Memory Management Tips #

Memory leaks are particularly nasty because you won’t notice them for a while.

And even if you do, the program doesn’t always crash - it might just get really slow because it keeps swapping new memory into RAM.

Some tips:

  • Every malloc needs a corresponding free.
  • If you have a make_X function, have a free_X function.
  • Document your memory interface so you know what memory the library handles and what memory you need to handle.
  • Every piece of memory needs one “owner” to handle malloc and free.

For Next Time #

  • Read Head First C, Chapter 6.
  • Finish Homework 5 (or let me know if you need more time).
  • Take care of yourselves, and stay well.