-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows Support #379
base: main
Are you sure you want to change the base?
Windows Support #379
Conversation
Add directory where asan DLL is to path when running. Improve diagnostics
Co-authored-by: Blake Johnson <johnsonblake1@gmail.com>
Nice! Does |
I added a function for setting up a Windows JobObject so that all child processes are cleaned up when cargo-fuzz is terminated. |
Hmm trying it with
Where the test project is just an empty Rust template with an empty fuzzer. |
I did a dumpbin, and it looks like it requires some of the symbols the asan DLL provides. So on Windows it unconditionally needs to be linked with |
This is because any cargo-run needs to be able to run the binary :)
Wow this library desperately needs golden file testing. The weird |
Note: I will clean up the commits once it's mostly working
This crate is quite close to supporting Windows. The crates will already build without issue. Things to do:
clang_rt.asan_dynamic-x86_64.dll
is in to $PATH of the fuzzer processWith this change it is possible to run the fuzzers too.
This directory is not on PATH by default, so the binary cannot load the DLL when run. It is recommended to add it to PATH before running the binary. It somewhere like
C:\Program Files (x86)\Microsoft Visual Studio\[MSVC VERSION]\BuildTools\VC\Tools\MSVC\[RT VERSION]\bin\Hostx64\x64
asan is fairly new to MSVC so it will only exist on versions newer than 2019.
This DLL resides in the same directory as
link.exe
&cl.exe
so the most accurate way to obtain it is to do the same process rustc does to get the location oflink.exe
. This ensures that the runtime & msvc version matches the one used to compile the binary.Note: this is required for
sanitizers = none
as well. Windows does not support any other sanitizers at this time.There are errors that are *nix specific that need to be fixed up. It is mainly fixing str paths that will be displayed incorrectly on Windows.
init_twice
add_twice
build_dev
build_all
build_one
run_a_few_inputs
run_alt_corpus
run_diagnostic_contains_fuzz_dir
run_one_input
run_without_sanitizer_with_crash
run_with_crash
run_with_coverage
tmin
Ensure child processes are always terminated
The win32 Job Objects API is what is needed for this. Essentially, get its info, set the info so that it has JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE set.
For some reason on my work computer the fuzzer just hangs when it opens, not doing anything. At home it seems to work as expected. I'm not sure why.
Looks like every thread it hanging out in `NtWaitForAlertByThreadId`. IDK what that means.