CSc 352 Freeing Dynamically Allocated Memory Saumya Debray

CSc 352 Freeing Dynamically Allocated Memory Saumya Debray Dept. of Computer Science The University of Arizona, Tucson debray@cs. arizona. edu

Motivation • Dynamically allocated memory should be freed when no longer needed – The C runtime system does not automatically reclaim memory – memory leaks increase the program’s memory footprint • this can lead to slow performance, program crashes • This needs to be done with care: – too-aggressive freeing can lead to program errors – too-passive freeing can miss memory allocated “behind the scenes”, e. g. , through strdup(). 2

Issues • Understanding when dynamic memory allocation happens – explicit (by the programmer) – implicit (by library routines) • Through the course of the program: – identifying when memory is no longer needed – being aware of multiple pointers to a block of memory • Identifying and fixing memory leaks 3

Understanding dynamic memory allocation • Dynamic allocation can be explicit or implicit – explicit: when the programmer invokes malloc, calloc, etc. – implicit: when the memory allocation happens “behind the scenes” in a library routine • • • getline strdup GNU extension to scanf fopen … In general, if memory appears “by magic” at runtime, chances are it’s being allocated implicitly. 4

Freeing up memory • Use free(p) when a memory block is no longer needed – p is a pointer to a block of memory previously allocated through malloc or calloc • Pitfalls: – accessing a previouslyfreed block is an error – freeing a block of memory twice is an error pointer watch out for multiple ways to reach a memory block malloc’d memory block 5

Freeing up memory • General approach: – free up memory “hanging off” a block of memory – grab any pointers you need to traverse the rest of the data structure – then free the block itself 1 deallocate memory “hanging off” this node 2 grab this pointer 3 free this block 6

Finding memory leaks 1 use valgrind to determine whether the program has memory leaks 7

Finding memory leaks 2 indicates where the lost memory was allocated 8

Finding memory leaks 2 forgot to fclose() after reading the file! 9

After fclose-ing the input stream less leakage than before, but still quite a bit need to free the linked list of states 10

Freeing up a linked list 1 naïve code to free the nodes in a linked list 11

Freeing up a linked list 2 state. List st 0 st 1 12

Freeing up a linked list 3 • no memory errors • less memory being leaked • but some leakage persists! • reason: structures “hanging off” states not being freed // a DFA state typedef struct vertex { char *name; struct edge *transitions; bool is. Final; struct vertex *next; } state; // a transition between states typedef struct edge { char ch; struct vertex *from, *to; struct edge *next; } edge; 13

Freeing up a linked list 4 Solution: free up the edges “hanging off” each state before freeing hat state 14

Freeing up a linked list 4 a lot better! but some leakage still left! 15

Freeing up a linked list 4 // a DFA state typedef struct vertex { char *name; struct edge *transitions; bool is. Final; struct vertex *next; } state; 16

Freeing up a linked list 5 17

Summary • Should free up dynamically allocated memory when done – Use valgrind to identify memory leak sources! • Needs to be done carefully – freeing up “live” memory will result in program errors • Pay attention to implicitly-allocated memory, e. g. : – file pointers – strings allocated through strdup() – when freeing up a struct, first free up any unused memory “hanging off” the struct 18