Fuzz testing with fault injection

[brson]

The semantics of rust tasks allow them to fail unexpectedly. Currently the two scenarios where this happen are:

• Immediately before or after any yield (e.g. send and receive). In the future the compiler will insert yield points as well
• When stack growth fails

The story for how tasks should cope with this are unclear. Right now there is a function unkillable which creates a scope where tasks cannot be killed by other tasks, but it does not do anything about hitting the end of the stack.

There is a lot of unsafe code in the core and standard libraries that is not aware of its obligations to cope with random failure.

I would like to instrument the runtime and core libraries to allow failure to be injected at various points, then create a tool that takes a crate of tests and runs them while poking at them with the fail stick.

[graydon]

nominating for well covered

[emberian]

Triage bump

[huonw]

Triage: this is probably improving (as in, people are occasionally noticing that something is not failure-safe and fixing it, hopefully faster than new non-failure safe code is being introduced), but there's still no automated tool for it.

A very crude way to do this for a subset of the functions in the stdlib would be to have tests passing |_, ..., _| fail!() to any functions that take a closure (although there are fewer of these now, with external iterators); clearly this only gets a very limited number, but possibly the ones that will most commonly fail "randomly".

[emberian]

Would it be possibly to hack this together with gdb? I'm thinking "break randomly, call <function that does what fail! does>, continue".

[bstrie]

Is this a bug asking for an instrument to perform fuzz testing in general, i.e. a resurrection of #414?

[pnkfelix]

Accepted for P-low.

[treeman]

Triage bump.

[steveklabnik]

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#608