Hi,
the `vm-implied` fuzzer panics when executing this testcase:
```javascript
try {
new function() {
while (this) {}
}();
} catch {
}
```
`internal error: entered unreachable code: The NoInstructionsRemain native error cannot be converted to an opaque type`
Handling the `NoInstructionsRemain` error upfront instead of going through the VM exception handling logic seems to work.
This Pull Request offers a basic VM fuzzer which relies on implied oracles (namely, "does it crash or timeout?").
It changes the following:
- Adds an insns_remaining field to Context, denoting the number of instructions remaining to execute (only available when fuzzing)
- Adds a JsNativeError variant, denoting when the number of instructions has been exceeded (only available when fuzzing)
- Adds a VM fuzzer which looks for cases where Boa may crash on an input
This offers no guarantees about correctness, only assertion violations. Depends on #2400.
Any issues I raise in association with this fuzzer will link back to this fuzzer.
You may run the fuzzer using the following commands:
```bash
$ cd boa_engine
$ cargo +nightly fuzz run -s none vm-implied
```
Co-authored-by: Addison Crump <addison.crump@cispa.de>
This Pull Request offers a fuzzer which is capable of detecting faults in the parser and interner. It does so by ensuring that the parsed AST remains the same between a parsed source and the result of parsing the `to_interned_string` result of the first parsed source.
It changes the following:
- Adds a fuzzer for the parser and interner.
Any issues I raise in association with this fuzzer will link back to this fuzzer.
You may run the fuzzer using the following commands:
```bash
$ cd boa_engine
$ cargo +nightly fuzz run -s none parser-idempotency
```
Co-authored-by: Addison Crump <addison.crump@cispa.de>
José Julián Espina
Iban Eguia Moraza
Addison Crump
Mrmaxmeier
Addison Crump