rust-fuzz / cargo-fuzz Goto Github PK
View Code? Open in Web Editor NEWCommand line helpers for fuzzing
Home Page: https://rust-fuzz.github.io/book/cargo-fuzz.html
License: Apache License 2.0
Command line helpers for fuzzing
Home Page: https://rust-fuzz.github.io/book/cargo-fuzz.html
License: Apache License 2.0
If I have a directory like this:
my_first_binary
my_second_binary
Cargo.toml
Where Cargo.toml only contains something like this:
[workspace]
members = [
"my_first_binary",
"my_second_binary"
]
Then initialization fails on an unwrap of None on an Option (though it doesn't say which one). It would be nice if cargo-fuzz could worked with workspaced projects so that it has one folder with targets for all binaries in the workspace.
existing/broken: $ cargo fuzz --fuzz-target fuzzer_script_1
Fix: $ cargo fuzz --target fuzzer_script_1
Currently the artefacts are just dumped into the fuzz folder. We should create a corpus dir and pass it to the binary. We should also set up the -artefact-prefix
arg
In order to have some focused fuzzing, I'd like to be able to expose some private methods only when fuzzing. However, I don't see how to pass in Cargo feature flags:
$ cargo fuzz run expression --features=test --release
error: Found argument '--features' which wasn't expected, or isn't valid in this context
$ cargo fuzz run --features=test expression --release
error: Found argument '--features' which wasn't expected, or isn't valid in this context
$ cargo fuzz --features=test run expression --release
error: Found argument '--features' which wasn't expected, or isn't valid in this context
Even better, it might be nice if cargo fuzz
implicitly set a feature the same way that cargo test
does.
$ git clone 'https://github.com/serde-rs/json.git' && cd json
$ cargo fuzz --init
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /checkout/src/libcore/option.rs:323
stack backtrace:
1: 0x5623cfbb8d89 - std::sys::imp::backtrace::tracing::imp::write::hbb14611794d3841b
at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:42
2: 0x5623cfbbdf6e - std::panicking::default_hook::{{closure}}::h6ed906c7818ac88c
at /checkout/src/libstd/panicking.rs:351
3: 0x5623cfbbdb74 - std::panicking::default_hook::h23eeafbf7c1c05c3
at /checkout/src/libstd/panicking.rs:367
4: 0x5623cfbbe36b - std::panicking::rust_panic_with_hook::hd0067971b6d1240e
at /checkout/src/libstd/panicking.rs:545
5: 0x5623cfbbe1f4 - std::panicking::begin_panic::h1fd1f10a3de8f902
at /checkout/src/libstd/panicking.rs:507
6: 0x5623cfbbe169 - std::panicking::begin_panic_fmt::haa043917b5d6f21b
at /checkout/src/libstd/panicking.rs:491
7: 0x5623cfbbe0f7 - rust_begin_unwind
at /checkout/src/libstd/panicking.rs:467
8: 0x5623cfbe860d - core::panicking::panic_fmt::he9c7f335d160b59d
at /checkout/src/libcore/panicking.rs:69
9: 0x5623cfbe8544 - core::panicking::panic::hb790668694ff6b20
at /checkout/src/libcore/panicking.rs:49
10: 0x5623cf93bebc - <core::option::Option<T>>::unwrap::hbd802f172b858ee2
at /checkout/src/libcore/macros.rs:21
11: 0x5623cf949cc8 - cargo_fuzz::init_fuzz::hca902791dd2a2f92
at /home/nagisa/Documents/rust/cargo-fuzz/src/main.rs:80
12: 0x5623cf949334 - cargo_fuzz::main::hba96e14eae3eda3f
at /home/nagisa/Documents/rust/cargo-fuzz/src/main.rs:46
13: 0x5623cfbc526a - __rust_maybe_catch_panic
at /checkout/src/libpanic_unwind/lib.rs:98
14: 0x5623cfbbeb16 - std::rt::lang_start::hb7fc7ec87b663023
at /checkout/src/libstd/panicking.rs:429
at /checkout/src/libstd/panic.rs:361
at /checkout/src/libstd/rt.rs:57
15: 0x5623cf94d502 - main
16: 0x7ff37431d290 - __libc_start_main
17: 0x5623cf93a949 - _start
18: 0x0 - <unknown>
Similar to what afl.rs has:
https://rust-fuzz.github.io/afl.rs/
https://github.com/rust-fuzz/afl.rs/tree/master/docs/src
I'd be willing to write it if others think it'd be helpful.
It also might make sense to have a new repository: rust-fuzz/book
Libstd isn't built with sanitizer support. Perhaps we should release a version that is.
Hi,
cargo-fuzz is not working anymore here, but I cannot find the source of the problem. The error is triggered when starting the fuzzer:
$ cargo fuzz run fuzzer_script_1
...
Running `fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1 -artifact_prefix=/home/pollux/CODE/RUST/der-parser/fuzz/artifacts/fuzzer_script_1/ /home/pollux/CODE/RUST/der-parser/fuzz/corpus/fuzzer_script_1`
==6747==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING.
==6747==ASan shadow was supposed to be located in the [0x00007fff7000-0x10007fff7fff] range.
==6747==Process memory map follows:
0x0005eba8d000-0x0005ebc94000 /home/pollux/CODE/RUST/der-parser/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1
0x0005ebe93000-0x0005ebe98000 /home/pollux/CODE/RUST/der-parser/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1
0x0005ebe98000-0x0005ebe9f000 /home/pollux/CODE/RUST/der-parser/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1
0x0005ebe9f000-0x0005edd2a000
0x0005edd2a000-0x0005f18ed000
0x0005f18ed000-0x0005f18ee000 [heap]
0x03a358fd1000-0x03a359323000
0x03a359323000-0x03a359426000 /lib/x86_64-linux-gnu/libm-2.24.so
0x03a359426000-0x03a359625000 /lib/x86_64-linux-gnu/libm-2.24.so
0x03a359625000-0x03a359626000 /lib/x86_64-linux-gnu/libm-2.24.so
0x03a359626000-0x03a359627000 /lib/x86_64-linux-gnu/libm-2.24.so
0x03a359627000-0x03a3597bc000 /lib/x86_64-linux-gnu/libc-2.24.so
0x03a3597bc000-0x03a3599bb000 /lib/x86_64-linux-gnu/libc-2.24.so
0x03a3599bb000-0x03a3599bf000 /lib/x86_64-linux-gnu/libc-2.24.so
0x03a3599bf000-0x03a3599c1000 /lib/x86_64-linux-gnu/libc-2.24.so
0x03a3599c1000-0x03a3599c5000
0x03a3599c5000-0x03a3599db000 /lib/x86_64-linux-gnu/libgcc_s.so.1
0x03a3599db000-0x03a359bda000 /lib/x86_64-linux-gnu/libgcc_s.so.1
0x03a359bda000-0x03a359bdb000 /lib/x86_64-linux-gnu/libgcc_s.so.1
0x03a359bdb000-0x03a359bdc000 /lib/x86_64-linux-gnu/libgcc_s.so.1
0x03a359bdc000-0x03a359bf4000 /lib/x86_64-linux-gnu/libpthread-2.24.so
0x03a359bf4000-0x03a359df3000 /lib/x86_64-linux-gnu/libpthread-2.24.so
0x03a359df3000-0x03a359df4000 /lib/x86_64-linux-gnu/libpthread-2.24.so
0x03a359df4000-0x03a359df5000 /lib/x86_64-linux-gnu/libpthread-2.24.so
0x03a359df5000-0x03a359df9000
0x03a359df9000-0x03a359e00000 /lib/x86_64-linux-gnu/librt-2.24.so
0x03a359e00000-0x03a359fff000 /lib/x86_64-linux-gnu/librt-2.24.so
0x03a359fff000-0x03a35a000000 /lib/x86_64-linux-gnu/librt-2.24.so
0x03a35a000000-0x03a35a001000 /lib/x86_64-linux-gnu/librt-2.24.so
0x03a35a001000-0x03a35a003000 /lib/x86_64-linux-gnu/libdl-2.24.so
0x03a35a003000-0x03a35a203000 /lib/x86_64-linux-gnu/libdl-2.24.so
0x03a35a203000-0x03a35a204000 /lib/x86_64-linux-gnu/libdl-2.24.so
0x03a35a204000-0x03a35a205000 /lib/x86_64-linux-gnu/libdl-2.24.so
0x03a35a205000-0x03a35a377000 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22
0x03a35a377000-0x03a35a577000 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22
0x03a35a577000-0x03a35a581000 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22
0x03a35a581000-0x03a35a583000 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22
0x03a35a583000-0x03a35a587000
0x03a35a587000-0x03a35a5aa000 /lib/x86_64-linux-gnu/ld-2.24.so
0x03a35a76c000-0x03a35a782000
0x03a35a790000-0x03a35a7a6000
0x03a35a7a6000-0x03a35a7a8000 [vvar]
0x03a35a7a8000-0x03a35a7aa000 [vdso]
0x03a35a7aa000-0x03a35a7ab000 /lib/x86_64-linux-gnu/ld-2.24.so
0x03a35a7ab000-0x03a35a7ac000 /lib/x86_64-linux-gnu/ld-2.24.so
0x03a35a7ac000-0x03a35a7ad000
0x03eca912c000-0x03eca914e000 [stack]
==6747==End of process memory map.
cargo-fuzz version 0.4.1
llvm & clang version 3.8.1 (Debian)
rustc 1.18.0-nightly
note: compiled kernel with grsecurity, I don't know if that is of any importance - cargo-fuzz 0.3.1 worked previously on the same kernel.
The same happens when creating a new crate (type lib) and adding a fuzzer.
It seems like RUSTFLAGS
are ignored when compiling the fuzzer script. This makes it impossible to fuzz crates that rely on e.g. AVX2.
#[export_name="rust_fuzzer_test_input"]
pub extern "C" fn go(data: &[u8]) {
let mut bt: BTreeSet<u64> = BTreeSet::new();
bt.insert(0);
}
#[export_name="rust_fuzzer_test_input"]
pub extern "C" fn go(data: &[u8]) {
let mut bt: HashSet<u64> = HashSet::new();
bt.insert(0);
}
Both of these functions cause a AddressSanitizer error for me. Here is the one for BTreeSet:
INFO: Seed: 765651658
INFO: Loaded 0 modules (0 guards):
Loading corpus dir: corpus
INFO: -max_len is not provided, using 64
#0 READ units: 20
=================================================================
==15413==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff8e0a6f10 at pc 0x55a091206598 bp 0x7fff8e0a60d0 sp 0x7fff8e0a60c8
ACCESS of size 0 at 0x7fff8e0a6f10 thread T0
#0 0x55a091206597 (/home/brain/src/roaring-rs/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1+0xf597)
#1 0x55a0912374f9 (/home/brain/src/roaring-rs/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1+0x404f9)
#2 0x55a091229463 (/home/brain/src/roaring-rs/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1+0x32463)
#3 0x55a091229503 (/home/brain/src/roaring-rs/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1+0x32503)
#4 0x55a09123e945 (/home/brain/src/roaring-rs/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1+0x47945)
#5 0x55a09124256a (/home/brain/src/roaring-rs/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1+0x4b56a)
#6 0x55a09124060f (/home/brain/src/roaring-rs/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1+0x4960f)
#7 0x55a09137970b (/home/brain/src/roaring-rs/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1+0x18270b)
Address 0x7fff8e0a6f10 is located in stack of thread T0 at offset 48 in frame
#0 0x55a091236f0f (/home/brain/src/roaring-rs/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1+0x3ff0f)
This frame has 5 object(s):
[32, 48) '_11' <== Memory access at offset 48 is inside this variable
[64, 136) 'iter'
[176, 200) '_6'
[240, 312) '_5'
[352, 424) '_4'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/home/brain/src/roaring-rs/fuzz/target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1+0xf597)
Shadow bytes around the buggy address:
0x100071c0cd90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100071c0cda0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100071c0cdb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100071c0cdc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100071c0cdd0: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
=>0x100071c0cde0: 00 00[f2]f2 00 00 00 00 00 00 00 00 00 f2 f2 f2
0x100071c0cdf0: f2 f2 00 00 00 f2 f2 f2 f2 f2 00 00 00 00 00 00
0x100071c0ce00: 00 00 00 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00
0x100071c0ce10: 00 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00
0x100071c0ce20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100071c0ce30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==15413==ABORTING
MS: 0 ; base unit: 0000000000000000000000000000000000000000
artifact_prefix='artifacts/'; Test unit written to artifacts/crash-da39a3ee5e6b4b0d3255bfef95601890afd80709
Base64:
Can other people reproduce this? I think this is because rust does not support AddressSanitizer. Can it be disabled for cargo-fuzz? There don't appear to be any flags to set to work around it.
First of all, the README says --fuzz-target
, but it looks like it's --target
now.
Secondly, with this script:
extern crate semver;
#![no_main]
extern crate fuzzer_sys;
use semver::Version;
#[export_name="LLVMFuzzerTestOneInput"]
pub extern fn go(data: &[u8]) {
let _ = Version::parse("1.2.3");
}
I get this
error: an inner attribute is not permitted in this context
--> fuzzers/fuzzer_script_1.rs:3:3
|
3 | #![no_main]
| ^
|
= note: inner attributes and doc comments, like `#![no_std]` or `//! My crate`, annota
te the item enclosing them, and are usually found at the beginning of source files. Oute
r attributes and doc comments, like `#[test]` and
`/// My function`, annotate the item follow
ing them.
error: main function not found
the no main stuff was generated by --init
. I'm very confused.
Being able to adjust some of the libFuzzer options (e.g max_len) would be useful, currently this seems to be only possible by editing the source of cargo-fuzz or using libFuzzer directly.
A simple solution would be to provide some pass-through argument to cargo fuzz that will passed to libFuzzer. (Similar to what rustc has with llvm options.)
I'm getting:
SUMMARY: AddressSanitizer: 433 byte(s) leaked in 3 allocation(s).
INFO: a leak has been found in the initial corpus.
INFO: to ignore leaks on libFuzzer side use -detect_leaks=0.
I don't know is it are real leaks because it triggered by Rc::new()
.
PS: maybe this issue should be treated as "How to pass custom flags to libFuzzer", which is not done yet (AFAIK).
I tried this but I don't understand what the output means. It'd be helpful if it was documented.
Probably should turn off most of the asan checks. I needed ASAN_OPTIONS=detect_odr_violation=0
to make it work on rust-url, otherwise it would bail very early.
Hi,
I wanted to checkout cargo fuzz but the cargo fuzz run fuzzer_script_1
fails on freshly created cargo workspace
cargo init test_fuzz
cd test_fuzz
cargo fuzz init
Fails with:
error: workspace member '/path/to/test_fuzz/Cargo.toml' is not hierarchically below the workspace root '/path/to/test_fuzz/fuzz/Cargo.toml'
I am testing on the latest stable:
rustc 1.15.1 (021bd294c 2017-02-08)
cargo 0.16.0-nightly (6e0c18c 2017-01-27)
To duble check with some other example from github
https://github.com/Manishearth/unicode-segmentation.git (checked out the fuzz
branch and corrected the [package.metadata]
in fuzz/cargo.toml) and unfortunately the result was identical.
error: workspace member '/path/to/unicode-segmentation/Cargo.toml' is not hierarchically below the workspace root '/path/to/unicode-segmentation/fuzz/Cargo.toml'
Am I doing something wrong or are the instructions outdated?
https://www.reddit.com/r/rust/comments/5va0mi/cargofuzz_an_easy_way_to_fuzz_your_crates/de0pyt5/
We may still need it so that libfuzzer itself isn't instrumented.
It's not directly related to the cargo-fuzz, more to the llvm.
I'm new to fuzz-testing and can't understand how long it takes to finish fuzzing. Is it endless? Is there a progress somewhere in the output?
Now I'm just shutting down it after ~10 minutes.
Running cargo fuzz --fuzz-target fuzzer_script_1
results in a Error: Entity not found
.
Discussed with @nagisa about this issue on IRC, the cause is
"since we started passing in the
--target=xxx
flag, it puts the executable infuzz/target/<TARGET>/debug
where cargo-fuzz looks for it infuzz/target/debug
"
Is there anything blocking 1.0? My main reasons for not 1.0-ing this earlier was that the exact mechanics were in flux (building libfuzzer, the fuzz/ dir, etc), and the CLI was uncertain.
Now we have a proper CLI that probably won't change. We don't do a special libfuzzer build anymore. The fuzz scripts are much cleaner (macros!) and while we may add quickcheck support later, I don't think that will be backwards-incompatible.
Is there anything else we need to decide, or issues that should be fixed, before going 1.0?
Add the ability to choose between debug/release. Pass down any other useful rustc flags.
If the program panics an artifact is written. I then try to fix the bug causing the panic. Now I want to check if I really fixed the bug. A command like
cargo fuzz check my_fuzzer crash-2c66bb9f0dabeaf158f68a7eea3b5033080173c3
would be useful that invokes go(data)
with this artifact again.
According to the tutorial, libfuzzer supports a -print_coverage=1
option to print out some basic coverage information.
This doesn't seem to work with cargo fuzz
at the moment:
Running `target/x86_64-unknown-linux-gnu/debug/fuzzer_script_1 -artifact_prefix=artifacts/ -max_len=200 -dict=dictionary.txt -print_coverage=1 corpus`
Dictionary: 10 entries
INFO: Seed: 1877614280
INFO: Loaded 0 modules (0 guards):
Loading corpus dir: corpus
#0 READ units: 108
#108 INITED cov: 1584 corp: 83/10958b exec/s: 0 rss: 29Mb
#8192 pulse cov: 1584 corp: 83/10958b exec/s: 4096 rss: 82Mb
#16384 pulse cov: 1584 corp: 83/10958b exec/s: 5461 rss: 133Mb
#32768 pulse cov: 1584 corp: 83/10958b exec/s: 5461 rss: 232Mb
#65536 pulse cov: 1584 corp: 83/10958b exec/s: 6553 rss: 414Mb
^C==22321== libFuzzer: run interrupted; exiting
INFO: __sanitizer_symbolize_pc or __sanitizer_get_module_and_offset_for_pc is not available, not printing coverage
I'm not sure if this is the right way to get coverage or not, but it would certainly be interesting to see if there are any big chunks of my code that haven't been hit. (It's been 120 million runs since I last saw a new basic block, so I think this run has plateaued, and it's worth manually checking coverage now.)
I have a fuzz function that translates 12 bytes to a CAN frame. 4 for the header and up to 8 for the payload. If the fuzzer gets passed less than 4 or more then 12 it will reject and return immediately. This still results in a case in the corpus.
It would be nice to be able to return a result that signals that the input is not valid at all and that it will not end up in the corpus. Maybe even something like:
enum FuzzerResult {
InputToShort,
InputToLong,
ErrorInHarness,
}
This is a known issue:
I just figured it'd be a good idea to have some notice here to save other Windows users from having to find the answer themselves. (Maybe add a note to the README as well?)
This is the kind of error message you get:
==6089==Sanitizer CHECK failed: [...]/sanitizer_common/sanitizer_procmaps_linux.cc:57 ((IsOneOf(*current_, 's', 'p'))) != (0) (0, 0)
Not very helpful, but Googling Sanitizer CHECK failed IsOneOf
turned up the above issues.
It should cd to a test crate directory, that contains a single function which panics on an input of size 6 or something, then fuzz init, edit the fuzz target to call this function, run the fuzz target, and ensure a crashfile is produced of the correct length.
๐ ๐
There's supposedly support for libfuzzer on MacOS in the latest LLVM (I think?). Opening this here as a tracking issue and reminding us we might need to change what was added here.
Add colors, use error_chain
, etc.
In BurntSushi/rust-snappy#5, it looks like the error is coming from Lazy::get()
.
This possibly has the same root cause as #81, but I don't know enough about how lazy_static
works to be able to say for sure.
$ cargo-fuzz --init
Invalid arguments.
Usage:
cargo fuzz --init
Increasingly inclined to move from docopt to clap. I may get around to that eventually. Move to clap should also help with making a more flexible parser to pass various extra options to the executable and rustc.
@nagisa has mentioned this a few times
I just opened a PR to fix the build on Windows. It would be great to setup AppVeyor to ensure future PRs are built correctly on Windows as well.
Anything using a custom allocator cannot be fuzzed, even if the same allocator is chosen in the fuzzer script.
Would be nice if we could cargo fuzz --fuzzer afl
on binary crates. Or something. Might need to set up the whole LLVM shebang.
cc @frewsxcv
Considering cargo fuzz --fuzz-target <fuzz target>
is the main command here and going to be called the most, it seems unfortunate it's a pretty long CLI call. Maybe we should migrate to cargo fuzz <fuzz target>
? Thoughts?
According to the libfuzzer documentation, there's a -fsanitize-coverage=trace-cmp
flag that looks interesting:
Tracing CMP instructions
With an additional compiler flag -fsanitize-coverage=trace-cmp (see SanitizerCoverageTraceDataFlow) libFuzzer will intercept CMP instructions and guide mutations based on the arguments of intercepted CMP instructions. This may slow down the fuzzing but is very likely to improve the results.
Value Profile
EXPERIMENTAL. With -fsanitize-coverage=trace-cmp and extra run-time flag -use_value_profile=1 the fuzzer will collect value profiles for the parameters of compare instructions and treat some new values as new coverage.
...
This feature has a potential to discover many interesting inputs, but there are two downsides. First, the extra instrumentation may bring up to 2x additional slowdown. Second, the corpus may grow by several times.
Is there any easy way to turn this on using cargo fuzz
?
I noticed that I wanted to pretty print the artefacts. Especially because sometimes the raw artefact is a bit hard to read.
The code I need for that is very similar to the actual fuzzer. It would be nice to have a pretty print function for artefacts. It should be used standalone to show an artefact file. But it can also be used during runs to print a more meaningful message than a set of bytes
For fuzzing, I always have to make sure my crate type is set to rlib, or rlib and staticlib. Reversing the order or adding the bin crate type leads to link errors. Is this expected or specific to my setup? Happy to provide a sample if necessary.
Ideas?
= note: /home/steve/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-cd0ca85e71f914ca.rlib(core-cd0ca85e71f914ca.0.o): In function `core::panicking::panic_fmt':
/checkout/src/libcore/panicking.rs:69: undefined reference to `rust_begin_unwind'
collect2: error: ld returned 1 exit status
I'm not doing anything special with regards to panics.
For now when we cannot find the executable (which tends to move around due to all the changes and cargo being weird) we print just
Error: entity not found
which is extremely uninformative.
2 action points:
[1]: cargo root can be easily annotated with [package.metadata.fuzz]
(cargo does not complain about non-existing toml key in [package.metadata]
).
By adding the following to fuzz/Cargo.toml
:
+[profile.dev]
+opt-level = 3
โฆI improve fuzzer throughput from:
#524288 pulse cov: 3738 corp: 80/10238b exec/s: 1420 rss: 574Mb
...to:
#1048576 pulse cov: 1584 corp: 79/10254b exec/s: 6808 rss: 594Mb
What would the tradeoffs be for including this in the default Cargo.toml
, or at least documenting it?
Maybe I missed something in the docs But I'd like to request the following feature:
Add a function that will be called once before the fuzzing starts to set up stuff needed for fuzzing. Maybe with a method to pass that data as an argument to the fuzz function.
Two reasons:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.