This is an individual assignment. All work must be your own. You should not look at any other student's work (in whole or in part, on paper or on screen), nor allow anyone else to look at yours, during the course of this assignment.
Turn in your answers to these questions to Lab 4 in the CS Homework system. Plain text only. Typed.
This lab will ask you to think about memory management and the causes of memory leaks in programs.
Here are a set of programs, each of which has some memory managment bug in it.
Your job is to analyze each program and figure out what is wrong with the memory management in the code and how to fix the code.
Professional software development projects track reports of software bugs. Pretend you work at a company and you have been told by your boss to tackle the list of reported bugs, fix them, and document your fixes.
Note that most of the brokenX.c programs are stripped-down, and not doing any work that isn't visible to the reader of the code. For purposes of this assignment, all of the above could be "fixed" by simply stripping them down to an empty main(). Doing that will earn a student NO points.
Some of the programs above do try to perform illegal memory accesses, or otherwise behave in dangerous ways. For this reason, if you have administrator / root access on the computer you use for this assignment, log out of your administrator account before working on this assignment. Also, save any other projects you might be working on, in case the computer crashes or runs out of memory. (Your computer's operating system should protect you. Should.)
For some of the broken programs, running them with larger numbers may cause interesting (and possibly clue-full) errors. (Hint: on Unix machines, "Ctrl-C" can be used to kill a command-line program that is not responding.) For at least one of the programs, the memory leak is very small and it is likely the program will seem to run fine every time.
What your grade is based on:
For each brokenX.c program that you figure out a fix for, write up a report on how you tested the code, what you observed, what you think the bug's cause is, and your suggested fix.
Your grade is based on your report of your debugging progress and results, not on the fix itself. Turning in only a fixed line or so of code will earn almost no points.
If you found an input (or more than one) that forced the program to crash, include the exact command line command that caused the crash. In a real software development environment, an input that forced buggy software to crash would be added to the regular test suite for the software, so that regression testing could verify, in future, that future modifications do not re-introduce a previously fixed bug.
Be specific in reporting your fix. For example, you could write something like, "I replaced the line of code 'printf("%d \t", counter);' on line 10 of the source code, with 'printf("%d \t", counter); printf("%d \t", counter);'".
Each brokenX.c program that you find a fix for is independent of the others. For each program you find a fix for, turn in a report.
Turn in your reports to Lab 4 in the CS Homework system.
Valuable Hints:
1. The programs do compile on the CS Lab computers, when booted into Mac OS. If you have trouble compiling, try using ssh to log in to a CS Lab computer or visit the professor's office hours.
2. You are to assume that memory is being allocated for some purpose, that arrays are being used, that infinite loops are intentional and needed, that functions are doing useful work. (Assume the useful code has been removed to make your bug-finding task easier, and the useful code will be added back in later.)