And also, thank you for the link to that valuable thread discovering more about @disableInstrumentation(). One of the merges suggest that it’s nearly essential, to avoid real trouble with premature access to thread-local storage, but once that pitfall is past, and the testing is underway, it seems that motivation could disappear. So, perhaps an approach would be to document a scope-local @enableInstrumentation() (I see that no such thing currently exists, and this isn’t surprising - since fuzzing runs as its own process, it’s fine for instrumentation to be left off indefinitely) - this would allow usercode to re-enable it in order to instrument. Another option might be to have a --fuzz-test, which would only run 10 or so iterations, by default, and would be single-threaded, and would be for userland fuzz code instrumenting/debugging purposes. It would be imperfect - not executed exactly as the “real” execution of a million iterations, but might be sufficient for the coder to get his code “right”, doing the right thing syntactically.