In D69537#1799790, @johanengelen wrote:

In D69537#1799478, @kcc wrote:

How is this going to work when one thread calls __sanitizer_for_each_extra_stack_range with another thread's ID,
while that other thread creates and discards frames, or while that other thread is being destroyed?

What is assumed is that the other threads have been stopped,

How is this going to work when one thread calls __sanitizer_for_each_extra_stack_range with another thread's ID,
while that other thread creates and discards frames, or while that other thread is being destroyed?

E.g. we have -print_stats that prints machine-readable output, we can do something like that and guarantee it doesn't change.

We want the user to also have user-readable output, though.

We're using an autogenerated trait for this anyway, so we get this for free.

BTW, may I ask you to provide some details of your Rust fuzz target examples?
(like the code of the fuzz target and the output with your patch)

Understood.
Before agreeing with the approach I'd like to hear from more users who need this and some details about their use cases. I've pinged some users.

In D70738#1772158, @Manishearth wrote:

I can totally see how this is helpful in some cases when running libFuzzer manually, but it can also be very annoying when the reproducer is large.
In any kind of automated scenario, it should be easy to add a separate binary that prints the inputs in human readable form.

This requires parsing the human-readable libfuzzer output though, which could change, and is also brittle

[sorry for delay, I was OOO]
So, this patch will cause LLVMFuzzerCustomOutput to be called on the reproducer input
which in turn will cause an arbitrarily large input to be printed to stderr (stdin)?
Or in fact, it will cause an arbitrary action to be performed with {Data,Size}

I'd prefer to not overload the public interface and this use-case sounds a bit too corner-case-ish.
Am I wrong?

please avoid #ifdefs -- they are pure evil.
Can you move this function to FuzzerUtil*.cpp?
In this case it will have it's own implementation in FuzzerUtilFuchsia.cpp

LGTM

LGTM, thanks!

I was actually hoping to get rid of this code entirely.
Why do you need this change?

LGTM

but please update the commit message to explain why this enables us to use __GLIBC_PREREQ

The asan bot is unhappy:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/35078/steps/check-llvm%20asan/logs/stdio

LGTM with one nit, also asking Matt for a second review.

I would prefer to not introduce this complexity.
For periodic pruning we can use an empty dir, like you describe.
For stats, we can use the overal corpus size (in bytes and in files)

LGTM

With a build command line, of course

clang++ -g -std=c++17 string-view-use-after-free.cc  -fsanitize=scudo

Maybe add an example?
something like my favorite

#include <iostream>
#include <string>
#include <string_view>

Vitaly, please take a look as well.

Frankly, I would like to see a parallel effort in Musl.
I've seen the recent comment at https://github.com/google/sanitizers/issues/1080#issuecomment-506565699
suggesting that Musl is not likely to accept this approach.
But please look at the situation from our perspective:
this amount of #ifdefs in the code will increase the cost of maintenance for us, w/o giving much to anyone who doesn't use Musl.
And this is a wrong technical decision anyway, as we've known in 2011 (just didn't have other choice)
and as we've confirmed with our current implementation of HWASAN in Bionic.

Actually, the test started failing in ubsan mode right after this commit. Please fix ASAP. Reproduce: build with -DLLVM_USE_SANITIZER=Undefined, then "ninja check-llvm"

This new test is currently failing on the ubsan build.
Could you please take a look?
I don't yet know is the breaking change.

I like the simplicity of the fix!
Please add a comment explaining the fix, and a test that verifies how it works.

Thanks for doing this!

Hi, 
I think this is causing a failure on the asan bot. Please fix or revert ASAP

LGTM given a test
Thanks!

All other dfsan functions will actually continue working - most of them just won't be needed.

make total sense, but please wait for Evgenii's LGTM

LGTM, thanks!