1 Dynamic Memory continued: Memory Leaks

Transcription

1 CS104: Data Structures and Object-Oriented Design (Fall 2013) September 3, 2013: Dynamic Memory, continued; A Refresher on Recursion Scribes: CS 104 Teaching Team Lecture Summary In this lecture, we continue our review of dynamic memory by talking about memory leaks: these occur when we dynamically allocate memory, and then lose all pointers pointing to it so we cannot free it any more. We also begin a review of recursion, in which functions call themselves. We review the basics with two easy examples: computing a factorial and performing binary search. 1 Dynamic Memory continued: Memory Leaks Last time, we learned how to request memory using malloc (or new) and release it back to the operating system using free (or delete). Let us look a little more at the things that can happen here. double *x; x = (double*) malloc(100*sizeof(double)); x = (double*) malloc(200*sizeof(double)); // We need a bigger array now! free(x); This code will compile just fine, and most likely will not crash, at least not right away. We correctly allocate an array of 100 double, use it for some computation, and then allocate an array of 200 double when we realize that we need more memory. But notice what happens here. The moment we do the second allocation, x gets overwritten with a pointer to the newly allocated memory block. At that point, we have no more recollection of the pointer to the previous memory block. That means we cannot read it, write it, or free it. When at the end of the code snippet, the program calls free(x), it successfully frees up the second allocated block, but we are unable to tell the operating system that we don t need the first block any more. Thus, those 800 bytes will never become available again (until our program terminates but for all we know, it may run for several years as a backend server somewhere). This kind of situation is called a memory leak: available memory is slowly leaking out of the system. If it goes on long enough, our program may run out of memory and crash for that reason. It could be quite hard to diagnose why the crash happened if it does after a long time of running. It is good practice to keep close track of the memory blocks you reserve, and make sure to free (or delete) memory pointed to by a pointer before reassigning it 1. A better version of the code above would be the following: double *x; x = (double*) malloc(100*sizeof(double)); 1 Unless, of course, you have another backup pointer to the memory you want. For instance, in the code snippet above, you might write y=x; before reassigning x; then, you could later call free(y); 1

2 free(x); x = NULL; x = (double*) malloc(200*sizeof(double)); free(x); x = NULL; That way, the memory gets released while we still have a pointer to it. You will recall from class that it is always good practice to immediately set pointers to NULL after deallocating their memory. In the middle of the code, that may seem very redundant: after all, we immediately overwrite x with another value. In fact, it is completely redundant. However, we still recommend that you add the line; for example, you may later insert some code between free(x) and the new assignment to x, and that could cause problems otherwise. And if you are worried about your program wasting time with unnecessary assignments, don t the compiler will almost certainly optimize that assignment away anyway, and the final code will look exactly the same. In class, someone also asked whether we could just free the memory by setting x = NULL; without calling free(x) first. That would only overwrite the pointer, but it would not tell the operating system that it can have the memory back. In other words, it would exactly create a memory leak. Whenever you want to return memory to the system, you must do so explicitly 2. As a side not, if you look up some of this information online or in other sources, keep in mind that the pool of memory where you allocate variables with new or malloc is called the memory heap. This is different from a data structure known as the heap which we will learn about later. Unfortunately, people (including us...) are not quite consistent in naming these. 2 Recursion The adjective recursive means defined in terms of itself. (If you Google recursion, you get the answer: Did you mean recursion? ) As computer scientists, we frequently run into recursion in the form of recursive functions, which are functions that call themselves (directly, or indirectly through another function). However, as we see below (in the next lecture), another very important application is recursive definitions of objects. We will explore recursion through three examples. 2.1 Computing Factorials The first one is to compute the factorial of n, which is defined as n! = n (n 1) (n 2) 2 1 = n i=1 i. Of course, we could use iteration (a simple for loop) to compute n!. int factorial(int n) int p=1; for (int i=1; i<=n; i++) p*= i; return p; Of course, this is a perfectly valid, and probably even the best, way to compute the factorial of a number. But instead, we would like to use this very easy example to illustrate how recursion works. Looking at the definition, we observe that 0! = 1 (by definition), and n! = n (n 1)!. This suggests a recursive solution: 2 There are other programming languages that do much more of the garbage collection and memory handling for you, but C/C++ is not one of them. 2

3 int factorial (int n) if (n==0) return 1; else return n*factorial(n-1); Notice that the function factorial calls itself; this is what makes this a recursive implementation. Students often have trouble thinking about recursion initially. Our instinct is often to make a complete plan for the computation: first multiply n with n 1, then with n 2, and so on, all the way to 1. In a recursive solution, we instead treat most of the work as a black box : we don t really worry how the call with parameter n 1 will obtain the correct results, and just trust that it does. (Of course, that only works if the function is actually correct.) Again, in a recursive solution, we don t have to think of every step, nor do we have to keep track of various intermediate results, as those are returned as values by the other function calls. Students getting started on recursion often try as hard as possible to have recursion emulate loops, by passing around global variables (or pointers to variables, which amounts to the same thing) that are altered and store intermediate results. This type of thinking can take a while to get used to, but once you firmly grasp it, a lot of things induction in CSCI 170 and dynamic programming in CSCI 270 will come to you much more easily. Two things that pretty much all correct recursive functions share are the following: A recursive function needs one or more base case: at some point, the function must hit a point where it will no longer call itself (like the n==0 case for the factorial). Otherwise, the function will keep calling itself forever, and eventually run out of stack memory. Recursive calls must have smaller inputs than the main input. In the case of the factorial function, the recursive call within factorial(n) was for factorial(n-1). In this case, it is clear that n 1 is smaller than n. In other cases, smaller refers to the remaining size of an array, or even a number that is closer to an upper bound. (For instance, the base case could be i==n, and the call with input i could be to i + 1.) Let us look quickly at two examples violating these conditions, and see what happens. int UCLAfact (int n) // apologies to our neighboring school if (n == 0) return 1; else return UCLAfact (n); // error: input not getting smaller! int bottomlessfact (int n) return n*bottomlessfact (n-1); // this doesn t stop! Neither of these functions will terminate. In the first example, we do have a base case, but the recursive call has the same size. It is of course correct that n! = n! (which is what the functions uses), but it doesn t help us compute it. In the second example, we do have a smaller input in the recursive call, but no base case, so the function will continue calling itself with different values forever (or until it runs out of stack space and crashes). 2.2 Binary Search Admittedly, computing factorials is not a very strong example to show why recursion is useful, since the iterative solution is short and elegant. However, we were able to illustrate some of the important properties of recursion with an easy enough general setup. Next, let us look at a somewhat more challenging task: 3

4 Given a (pre-sorted) array of integers in increasing order, find the location of a target element, or return -1 if it is not in the array. This is accomplished using the Binary Search algorithm: Check the middle of the remaining array. If the element is there, we are done. If the desired element is smaller, continue searching to the left of the middle element; otherwise, continue searching to the right. A corresponding iterative solution looks as follows: int binarysearch (int n, int* b, int len) int lo = 0, hi = len, mid; while(lo <= hi) mid = (hi+lo)/2; if (b[mid]==n) return mid; else if(n < b[mid]) hi = mid-1; else lo = mid+1; return -1; A recursive solution would look as follows instead: int recsearch(int n, int* b, int lo, int hi) if (hi < lo) return -1; // not in the array else int mid = (hi+lo)/2; // the midpoint of the array if (n == b[mid]) return mid; // we found it else if (n < b[mid]) return recsearch(n, b, lo, mid-1); // element to the left of the midpoint else return recsearch(n, b, mid+1, hi); // element to the right of the midpoint We then call the function as recsearch(n, b, 0, len). Whether you like the iterative or the recursive solution better here may be a matter of taste, but notice that there is a certain elegance to the recursive solution. When we have decided where the element must be (to the left or the right), rather than updating a variable and repeating, we simply ask the function to find it for us in that (correct) subarray, and return its return value unchanged. Notice that both implementations will work whether the array has an even or odd number of elements. If we hadn t written mid-1 and mid+1 for the recursive calls, we might have needed another base case when lo == hi. Let us check that we satisfy the two conditions above for a recursive solution to have a shot: If the array is empty (which is the case hi < lo), the function returns directly, reporting that the element was not found. If n is less than the midpoint, the function recurses on the left half of the array; otherwise, on the right half. In either case, because we eliminate at least the midpoint, the remaining array size is strictly smaller than before. One of the things that can be confusing about recursion is that there seem to be many active versions of the function at once. What is the value of variables like n, lo, hi, or mid? After all, different invocations of the function will have different values for them. To solve this conundrum, remember from our overview of memory that local variables are stored on the stack, and translated into memory locations by the compiler 4

5 and OS. Thus, when the function recsearch(12,b,0,10) calls recsearch(12,b,0,4), their variables lo, hi translate to completely different memory locations. When the call recsearch(12,b,0,4) executes, the values are lo=0, hi=4, and mid=2 will be computed. In the call recsearch(12,b,0,4), we instead have lo=0, hi=10, mid=5. The computer has no problem with the same variable name, as only one meaning of the variable is in scope at a time. 5