Challenge 1: Stepping Through the Off-By-One Bug in gdb — Possible Solution
====================================================================

#include <stdio.h>

int main() {
    int arr[5] = {1, 2, 3, 4, 5};
    int sum = 0;
    for (int i = 0; i <= 5; i++) {
        sum += arr[i];
    }
    printf("%d\n", sum);
    return 0;
}

$ gcc -g buggy.c -o buggy
$ gdb ./buggy
(gdb) break buggy.c:7
(gdb) run
(gdb) print i
$1 = 0
(gdb) continue
... repeat continue/print i until i = 5 ...
(gdb) print i
$6 = 5
(gdb) print arr[i]
$7 = 32601        (an arbitrary, unpredictable garbage value)

Report: once i reaches 5, arr[i] no longer refers to a valid element
of arr (which only has indices 0 through 4) -- print arr[i] shows
whatever value happens to occupy the memory immediately after arr's
last real element, which is not a meaningful part of the array at all
and varies unpredictably between runs/machines/compilers, exactly
matching the "no bounds checking, undefined behavior" description from
c1-6.

WHY THIS WORKS AS AN ANSWER
------------------------------
This walks through the actual gdb session (setting the breakpoint,
running, repeatedly stepping/printing to reach i=5) rather than just
describing what SHOULD happen, and correctly characterizes the value
shown at arr[5] as unpredictable garbage rather than a specific,
guessable number -- consistent with this being genuine undefined
behavior, not a deterministic off-by-one result.