test: Add a fuzzing harness for heap allocator

[nathaniel-brough]

No description provided.

[nathaniel-brough]

@microsoft-github-policy-service agree

[daanx]

This is very cool! Thanks Nathaniel (and apologies for the late reply). I would like to merge it in:

• I think the tests with MI_DEBUG_TSAN and MI_DEBUG_UBSAN failed -- I'll try to see why but if you can fix this that would be great.
• There is no "corpus" right? Should we include that as well? It would be great if we could make it part of the regular tests in the pipeline (if it doesn't take too long that is)

Best Daan

[nathaniel-brough]

@microsoft-github-policy-service agree

[nathaniel-brough]

This is very cool! Thanks Nathaniel (and apologies for the late reply). I would like to merge it in:

No worries mate!

• I think the tests with MI_DEBUG_TSAN and MI_DEBUG_UBSAN failed -- I'll try to see why but if you can fix this that would be great.

I don't seem to be able to get access to the build logs. But it looks like you've fixed it anyway.

• There is no "corpus" right? Should we include that as well? It would be great if we could make it part of the regular tests in the pipeline (if it doesn't take too long that is)

There isn't yet no. This fuzzer should be able to generate its own though. You just have to give it a corpus directory. e.g.

./fuzz-random-alloc -max_len=10000 corpus

We can manually add entries to the corpus, if you think it'd be worthwhile using a specific sequence of allocations. By manually adding to the corpus, you sort of give the fuzzer a hint as to what would be a "good" input.

In terms of adding it to the regular test pipeline. I'd recommend two approaches. Both integrate well together but can be used independently as well.

1. Using the clusterfuzz lite github action. This will manage the corpus between runs automatically and catch shallow bugs by running the fuzzer for a short period of time on every PR preventing bugs from being merged. This doesn't require using an external service and runs entirely on GH Actions.
2. Integrating with google/oss-fuzz which will run the fuzzer for a few hours every night across a distributed cluster. This is better for finding "deeper" bugs. It also has more powerful bisecting and other tools for understanding bugs.

I'm happy to go ahead and integrate either/both of those if you are interested?