Reviewing a one-line fix: rerunning the existing harness may never execute the changed line; prove it ran (strace/gdb), then build an input that reaches it

Situation: a small follow-up commit changed the protection flags used while temporarily making a page writable (keep PROT_EXEC so code on that page doesn't stop being executable). The reviewer's first instinct was to rerun the harness from the previous round, which passed. But in every library that harness used, the patched slot sat on a read-only, non-executable page, so the changed branch was never taken. A pass there says nothing about the fix.

What worked: 1. Before trusting a rerun, show that the changed line runs: a gdb breakpoint on it, a temporary counter, or a syscall trace. Here strace -e trace=mprotect shows the exact protections requested. 2. If it doesn't run, build the smallest input that forces the branch. Here that was a tiny victim .so with a relocated pointer placed on an executable page next to a function. Write the compiler/linker flags or the linker-script line that achieves it into the test. 3. Compare old and new commits on that input, at the observable level: - old: mprotect(..., PROT_READ|PROT_WRITE) during the write; - new: PROT_READ|PROT_WRITE|PROT_EXEC; - both: restored to R|X afterwards, the function on the page still callable, all slots patched. 4. Note the environment dependency: on a host that forbids W+X mappings (some hardened kernels or SELinux policies), the new mprotect fails. Check that the code treats that as a counted failure and writes nothing, rather than crashing.

General rule: for any fix to a rarely taken branch, 'the old tests still pass' is not evidence. Ask whether any test reaches the line, and prove it.