Add reproducible sources of panic to tests

[jdm]

Ideas:

• window.panic() for script
• -servo-panic property for CSS parsing/layout
• about:panic URL for network fetches
• some layout feature that generates a display list that triggers a panic

[jdm]

I also played around with a chaos mode idea that involved randomly simulating channel send/receive failure with some measure of probability. I tried to make the ChaosSender/ChaosReceiver interface identical to Sender/Receiver but got burned by our use of select!, so I never finished it.

[asajeffrey]

As discussed on IRC, we need to make sure we're not adding an attack surface by doing this, perhaps by putting the injected panics behind a build flag?

[larsbergstrom]

It would be super-nifty if we could create a fuzzing tool that randomly instrumented the binary with panic calls, but I suspect that won't work due to differences in compilation (e.g., exception hander frames) when a function can panic. So we can't just do like a debugger and overwrite with int 3 and see what happens... or can we? @alexcrichton might know.

If there's some way to make a generally-usable tool for Rust that would do this, I'd probably be willing to help find and fund a graduate student for a summer to work on it.

[alexcrichton]

Ah yeah unfortunately I don't know of any great way to inject a panic into already-compiled code (it would probably be unsound though?).

[asajeffrey]

Could we add a "chaos" cfg, which components could use to add random failure, with the idea that if we compile servo with chaos enabled, the resulting binary shouldn't panic?

[asajeffrey]

I started on a patch which would add randomly closing pipelines: asajeffrey@a9fb350

[asajeffrey]

The patch is now PR #10179, which has been r+d. This doesn't inject panic directly, but it does randomly kill pipelines without the usual clean-up, which results in panic.

[nox]

Is this still something we want?

[jdm]

I still believe that it's a good idea.