Segmentation Fault when using `AddressSanitizer` with `address_space_limit_mb` about centipede HOT 7 CLOSED

This one can be fixed relatively easy, by checking for ASAN/TSAN/MSAN in the runner at run-time, as opposed to at compile time. #203 sent

I just realized we have a similar problem with the interceptors, which should be present in the non-asan build, and should not be present in the ASAN build. See https://github.com/google/centipede/blob/main/runner_interceptors.cc
The solution we use internally is to build the centipede runner with the correct sanitizer.
Not sure it easily apples to the OSS world

from centipede.

Thanks for the report. We'll investigate.

from centipede.

My guess, w/o actually checking yet...
In runner.cc, inside SetLimits() we have if constexpr (kCanUseRlimitAs) { ...
kCanUseRlimitAs is supposed to be false when building with ASAN,
but it is computed via #ifndef ADDRESS_SANITIZER, which is not what ASAN sets by default
(in google-internal environment it does, for historical reasons).

from centipede.

Thanks!
I guess I can verify this theory later today by manually setting ADDRESS_SANITIZER to true and re-run : )

from centipede.

In the OSS version, we build the centipede runner with the default bazel flags and then link this run-time against the target, asan or not. I.e. the runner will be the same, it will have ADDRESS_SANITIZER=0.

So, I guess a better solution is to check for asan/tsan/msan at run-time as opposed to at-compile time. On it.

from centipede.

Thanks : )
I will test the new code today and keep everyone updated!

from centipede.

Just tested the latest code with a (short) experiment: It appears that the bug has been fixed : )
I will close this issue and update Centipede in OSS-Fuzz.
Thanks again!

from centipede.