American Fuzzy Lop VS sanitizers

There's some efforts to guide test generation for property based testing to make the instruction pointer explore as large a space as possible.

This effort is more mature in the fuzzing community. See eg American Fuzzy Lop https://github.com/google/AFL

What you're describing, just generating random input to test a program, is sometimes called "blind fuzzing" but the state-of-the-art is far beyond that. Maybe try reading through the documentation of e.g. https://github.com/google/AFL to see what a fuzzer does and why just producing random input isn't even scratching the surface.

for general riscv I used to use this https://github.com/google/AFL I dont know if it supports x64 tho.

Ex ( AFL, WinAFL, HonggFuzz, LibFuzzer, Jazzer )

I wrote this little fuzz test target in order to fuzz it with afl (under ASan and UBSan):

afl, which is trivial to apply to this program:

I made my own version of a TCL interpreter (well, a very TCL like langauge) derived from "picol" available at https://github.com/howerj/pickle. There are many different re-implementations and derivatives of this interpreter but they all seem very "crashy", this one has been significantly hardened by using a fuzzer on it which ran for months called American Fuzzy Lop https://lcamtuf.coredump.cx/afl/ . It is also more suitable for embedded use whilst still not having arbitrary restrictions like many other implementations.

On Linux afl is a very powerful bug-finding tool, and it's a great companion when doing code review. Composes well with ASan and UBSan.

b-, https://lcamtuf.coredump.cx/afl/

AddressSanitizer is really useful, it's similar to Valgrind but has much lower overhead.

And if you're up for it, I'd further recommend adding some ways to deal with buffer overflows in debug builds. The way I deal with this is by using Address-Sanitizer's manual poisoning api. Bonus point if you leave additional poisoned space between allocations so off by one errors are likely to end up in a poisoned region instead of nearby allocation.

It also doesn't hurt that Miri can find many kinds of unsafe violations even in unsafe blocks. Zig may get something like this one day, but even if it does, checking things at runtime is not a substitute for compile time -- the C++ Sanitizers haven't exactly solved the safety story for C++ even over a decade later.

This is where stuff like ASan is really useful.

Use: https://github.com/google/sanitizers/wiki/AddressSanitizer

Have you tried using tools like ASAN/LSAN or valgrind to confirm that there are indeed no memory leaks?

Compile with ASAN and UBSAn