Challenge 2: Why the Same Tool Might Catch a Bug on One Run But Not Another — Possible Solution
====================================================================

Per the chapter's own warn-box, valgrind, ASan, and UBSan only catch
bugs that are actually EXERCISED by the specific code path taken
during that particular execution -- they observe real, dynamic
behavior as the program actually runs, not every theoretically
possible behavior the source code could produce. This has a direct
consequence even with the EXACT SAME test input: if a program's
behavior depends on something not fully controlled by the input alone
-- e.g. the specific memory addresses malloc happens to return this
time, the exact interleaving of two threads' instructions (c3-3's own
race-condition material), or which of several equally-valid code paths
a nondeterministic condition happens to take -- the tool might observe
the buggy path on one run and a non-buggy path on another, purely by
chance, even with identical input.

Concretely: a use-after-free bug might only actually corrupt something
ASan or valgrind notices if the freed memory happens to get reused (and
thus modified) by a subsequent allocation before the dangling pointer
is dereferenced -- on a run where that memory happens to sit untouched
until the dangling read occurs, the read might return a value that
looks superficially fine, and the tool has nothing concrete to flag.
The underlying bug is identical in both runs; only the OBSERVABLE
SYMPTOM differs, based on incidental memory-allocator or thread-
scheduling behavior outside the test input's own control.

What this implies about test coverage more broadly: running a test
suite once, even under these tools, is not proof of a program's
correctness -- it's evidence about THAT SPECIFIC EXECUTION only.
Genuinely thorough testing needs to account for the possibility that a
real bug can hide behind a "lucky" run, which is part of why running
these tools repeatedly, under varied conditions (different loads,
different runs, sometimes with tools like TSan for thread scheduling
variation), and as routine CI practice (the chapter's own tip-box)
matters more than a single passing run ever proves on its own.

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies the specific mechanism (non-deterministic factors
like memory-allocator behavior or thread scheduling, not the test
input itself) that can cause identical inputs to produce different
observable symptoms, and draws the correct broader conclusion that a
single passing run under these tools is evidence about one execution,
not a general correctness guarantee.