Fix It From the Report

You are given a complete program and you write nothing from scratch. It reads a positive count, allocates a block of that many ints called values, reads the numbers into it, allocates a second block called doubled, sets each element of doubled to twice the matching element of values while adding it to a running total, and prints doubled total followed by that total. All of that logic is correct and none of it needs changing. What the program has instead are three memory mistakes, and your job is the one the sanitizer was built for: run it, read the report, work out which line is wrong, fix that one thing, and run it again. There are no TODO markers, because the reports are the instructions. The program compiles without a single warning, so nothing is waiting for you at compile time. Run the first test case and the first mistake stops the program before it prints anything, with a report reading ERROR: AddressSanitizer: heap-buffer-overflow, then READ of size 4 on the next line, then a stack frame reading #0 in main /app/code/main.c:44, then the line 0 bytes after 12-byte region, and then, under allocated by thread T0 here, a frame reading #1 in main /app/code/main.c:14. Work that through in the order the lesson gave you. The kind is a heap overflow, so a malloc block was touched outside itself. The failing line is 44, the first frame naming your own file. The block was allocated on line 14 and is 12 bytes, which for an int block is 3 elements with valid indices 0 through 2, and the address touched is 0 bytes after the end, which is element 3. Something reached one element past a three element block, and line 44 is inside a loop whose bound you can now check. Fix that and run again, because AddressSanitizer stops at the first error it meets and has nothing to say about anything later in the program. The second and third mistakes are of the other kind: the program runs to completion, prints exactly the right output, exits 0, and LeakSanitizer files its report afterwards, which is why this exercise sets fail_on_memory_leak and why byte-perfect output is not evidence of anything. One of those leaks is on the path where every number was read successfully and one is on the path where scanf gives up part way through, so a run that only exercises the happy path will not show you both. Read the allocation line at the bottom of each leak report to learn which of the two blocks was lost, since line 14 allocates values and line 31 allocates doubled. Every path through the finished program returns 0, exactly one free is written for each allocation on every route that reaches it, and a clean run prints nothing whatsoever on standard error.