Lecture 14 Notes. Brent Edmunds

Transcription

1 Lecture 14 Notes Brent Edmunds October 5, 2012

2 Table of Contents 1 Sins of Coding Accessing Undeclared Variables and Pointers Playing With What Isn t Yours The Heap: The Stack: Freeing Memory The Heap: The Stack: Valgrind Types of Leaks Definitely Lost Still Reachable and Indirect Loss Possibly lost Cache Grind and Call Grind

3 1. Sins of Coding Programming in C leaves you very vulnerable. Below, in no particular order, are commons mistakes that will cause unknown or possibly malicious behavior in your code. 1.1 Accessing Undeclared Variables and Pointers # include < stdio.h> # include < stdlib.h> int main () int i; int *c; int a [2]; int *b=( int *) malloc ( sizeof ( int ) *2) ; for (i =0;i <2; i ++) printf ("%d\n",a[i]); printf ("%d\n",b[i]); printf ("%d\n",*c); When a variable is first initialized, it can contain anything[3]. It might be nothing, it might be utter junk. When a pointer is initialized, there is no telling where it is pointing. Is it pointing to junk? Is it pointing to NULL? Can you even access it? Who knows. 1.2 Playing With What Isn t Yours void foo () int a [2]; int *b=( int *) malloc ( sizeof ( int ) *2) ; int i; /* Accessing */ for (i =0;i <3; i ++) printf ("%d\n",a[-i]); printf ("%d\n",b[i]); /* Corrupting */ for (i =0;i <3; i ++) a[-i]=i; b[i]=i; free (b); 3

4 Memory can either be allocated from the stack or the heap. This gives us a couple distinct flavors of error The Heap: Accessing: Always remember, you are not the only one using the heap. When the variable i in the above code hits three, the program will attempt to access memory in the heap it doesn t own. That memory could belong to veryimportantprogram.exe, or could be unused. In the former case, you will receive a segmentation fault[2], and in the latter, you will get junk. Corrupting: Always remember, you are not the only one using the heap. When the variable i in the above code hits three, the program will attempt to access memory in the heap it doesn t own. That memory could belong to wow.exe, or could be unused. In the former case, you will receive a segmentation fault. In the latter, you will have overwritten data to something that you may never be able to access again, as it could be allocated to another program. Worse, you have overwritten something another program will not overwrite, but use. Look up heap overflow for more information on this The Stack: Accessing: Junk, but from the stack. Corrupting: The stack has a very specific structure. Buffer overflows in the stack invariably mean overwriting pertinent data, possibly not in the current stack frame. Refer to past notes for more information about the stack. It is possible to destroy the structure of the stack frame by overwriting the stack pointer. Now, if you feel creative, you can try and guess the stack size and tamper with other variables, or change where pointers point. This can be used maliciously. If you break the stack hard enough, you will core dump. 1.3 Freeing Memory The Heap: If you attempt to free memory from the heap you already freed, you have no idea if it is free or if it has been allocated. Have a core dump for your trouble. Any and all memory you allocated from the heap[3], should be freed when you are done using it. Having code that continually allocates memory without deallocating results in longer runtimes, and program crashes. There is a very good argument for not using pointer arithmetic when it comes to memory from the heap. See the below code. void bar () int * a= malloc ( sizeof ( int ) *2) ; int i; for (i =0;i <2; i ++) *a=i; a ++; 4

5 free (a); It looks like you are freeing the memory you allocated, but it is in fact freeing a block of memory 4 bytes past the memory allocated. Note, you cannot use the free command from inside of a block of memory. void bar () int * a= malloc ( sizeof ( int ) *2) ; a=a +1; /* doesn t fly */ free (&a [1]) ; The Stack: You cannot free the stack. You cannot free the stack. You cannot free the stack. 5

6 2. Valgrind Valgrind[1] is a free program. To download, open the terminal and type sudo apt-get install valgrind. To run it on a piece of code hand it the executable. For instance, if I wanted to run valgrind on a piece of code foo.c: gcc foo.c -g -o foo valgrind./ foo Remember, always compile with -g when running valgrind. The -g flag will allow valgrind to be far more specific about where errors are occuring. So what does valgrind do? 1. It will intercept all writes that are illegal 2. It tracks all memory allocates 3. It suppresses errors of the same type 4. It provides a summary of leaks valgrind will not fix your problems for you. It will give you a list of problems and, possibly the general area in which they occur. The variety of error returns and cases are too numerous to be covered here. When in doubt, use intuition, guided by google, and informed by the user manual. What it will tell you, is how much memory you are leaking[1], and how. 2.1 Types of Leaks Definitely Lost The most common memory leak is a definite loss, allocated memory that is no longer pointed to. void foo () /* I have no way of freeing this memory */ int *a=( int *) malloc ( sizeof ( int )); Every time I call foo, I eat up 4 bytes of memory, as I have no way to free the memory allocated. But what about the other types of leak? Still Reachable and Indirect Loss Below is a horrible piece of code to demonstrate two of the types of leak that can occur, and how valgrind will report them. # include < stdlib.h> int *** foo () int *** array_matrix = malloc ( sizeof ( int ***) ); int ** matrix = malloc ( sizeof ( int **) ); int * row = malloc ( sizeof ( int *)); 6

7 array_matrix [0]= matrix ; array_matrix [0][0]= row ; array_matrix [0][0][0]=5; return array_ matrix ; main () int *** bar = foo (); This generates a pointer chain bar- matrix row- 5. Running the current code through valgrind will give you: ==4246== LEAK SUMMARY : ==4246== definitely lost : 0 bytes in 0 blocks ==4246== indirectly lost : 0 bytes in 0 blocks ==4246== possibly lost : 0 bytes in 0 blocks ==4246== still reachable : 12 bytes in 3 blocks ==4246== suppressed : 0 bytes in 0 blocks Still reachable means that you haven t lost any memory yet, as all of the memory allocated is accessable. In the above code, our pointer chain is unbroken, so it is still feasible to free all of the memory. There are 12 bytes, as a pointer is 4 bytes, and I have constructed 3 pointers. If you receive a still reachable leak, a couple frees will shore up your memory leaks. But, it pays to be very careful in how you free your memory. Currently, We know all of our allocated memory is reachable, and associated with the variable bar What happens if we free(bar)? ==4258== LEAK SUMMARY : ==4258== definitely lost : 4 bytes in 1 blocks ==4258== indirectly lost : 4 bytes in 1 blocks ==4258== possibly lost : 0 bytes in 0 blocks ==4258== still reachable : 0 bytes in 0 blocks ==4258== suppressed : 0 bytes in 0 blocks By freeing bar, we no longer have access to array, but array still points to row. We have lost row, as we cannot get to what points to it. This is called an Indirect Loss. Most often, indirect memory loss occurs a chain of pointers is broken[1]. Personally, I find them most often when structs have poorly defined deconstructors, and data structures have poorly written deletion functions. Of course, array is definitely lost, as nothing points to it Possibly lost See valgrind user manual, as an example will eat up a fair amount of space. Loosely, you need pointer chains, with a pointer to the inside of an allocated block of memory. 2.2 Cache Grind and Call Grind Valgrind comes with a couple of useful tools, Two of which are cache code profilers[1]. These profilers judge your codes interaction with the cache, a section of the cpu. So why do we care about code profiling? It guides code optimization. There is no reason to write an incredibly tight 7

8 Figure 2.1: example output from kcachegrind[4] piece of code, if there is no computational benefit. The output from cachegrind and callgrind allow the user to identify computational bottlenecks and inefficient code. As such, Callgrind and Cachegrind are things to use for optimizing, when disseminating code to the outside world. Cachgrind returns a flat profile of code, a profile that shows interaction with the cache at each function, on a function to function basis. Callgrind, being an extension of cachegrind, gives more information. Callgrind produces structured data that will identify not only the cost of a function, but takes into account all function calls within said function. To run callgrind/cachegrind: valgrind -- tool = callgrind [ callgrind options ] your - program [ program options ] valgrind -- tool = callgrind [ callgrind options ] your - program [ program options ] This generates an output file called callgrind.out. pid or cachegrind.out. pid. Frankly, reading this output file alone is horrible. Luckily, there is a program called kcachegrind[4] that provides a nice graphic interface to view what is going on in you code. It is available online for free. To run kcachegrind: kcachegrind callgrind. out.<pid > 8

9 Bibliography [1] Valgrind Developers. Valgrind [2] Greg Ippolito. C/c++ memory corruption and memory leaks [3] Manish Virmani. Pointers and memory leaks in c [4] Josef Weidendorfer. Kcachegrind