Update arbitrary

[fitzgen]

Updates arbitrary to its current unreleased master branch, and fixes compilation errors here.

[Manishearth]

This should be first.

[fitzgen]

I wanted to handle running a fuzz target with debug enabled on some input that doesn't parse as an arbitrary, so you still get some idea of what is going on rather than silent early exit. Does that make sense?

[Manishearth]

Wait, won't this make rust-fuzz run debug for every single fuzz test? Won't that slow things down? I thought the plan was to parse the crashdump file.

[fitzgen]

Wait, won't this make rust-fuzz run debug for every single fuzz test? Won't that slow things down? I thought the plan was to parse the crashdump file.

If you look at rust-fuzz/cargo-fuzz#206 what's happening is this:

• we run the fuzz target without RUST_LIBFUZZER_DEBUG_PATH until we get a crash
• cargo fuzz finds the new crash artifacts
• cargo fuzz re-runs the fuzz target on each crash artifact (should generally be just one) with RUST_LIBFUZZER_DEBUG_PATH set to a temp file
• cargo fuzz reads the temp file into a string and adds it to its helpful output

Notably, we don't run fuzzing with the env var set, so we don't debug format and write to disk for every single input.

Sound good?

[Manishearth]

Oh! I understand now! That's neat.

[Manishearth]

eventually should probably move to GHA

[fitzgen]

👍

[Manishearth]

feel free to cut a release, you should have access

[Manishearth]

We should also start using version numbers for libfuzzer-sys

[Manishearth]

(We can wait till both PRs land, test stuff out, and then update things with version numbers)

[fitzgen]

(We can wait till both PRs land, test stuff out, and then update things with version numbers)

Yeah -- I think we should probably move everything to 1.0.0 after we do some pre-release testing.

Do you have thoughts on that?

[Manishearth]

I'm okay with a 1.0, if we test it out first. We can even release a preview version of cargo fuzz that has a flag to use libfuzzer-sys:next, though that's probably not super necessary.

One leftover concern for 1.0 is it would be nice if we could stop doing the no_main stuff, but the current attempts to do that aren't that good.

[fitzgen]

Maybe we should do a 1.0-rc of both at the same time?

Honestly, I'm not too concerned with the no_main stuff. /me shrugs

[fitzgen]

It does probably make sense to keep using next as the main dev branch until we are confident in a 1.0, since all existing installs are using git master...

[Manishearth]

I think going directly for a release is fine since before this we weren't using versions. With that in mind we can probably publish the next branch without merging into master, and have cargo fuzz master use the published version for trying stuff out.

…

On Sat, Jan 11, 2020, 12:02 AM Nick Fitzgerald ***@***.***> wrote: Merged #53 <https://github.com/rust-fuzz/libfuzzer-sys/pull/53> into next. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <https://github.com/rust-fuzz/libfuzzer-sys/pull/53?email_source=notifications&email_token=AAMK6SC3K36PP26TZIOFD4TQ5C5KHA5CNFSM4KE63FQ2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOV42JZ4I#event-2939460849>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMK6SHF2OEANIZKME6MADDQ5C5KHANCNFSM4KE63FQQ> .