The build script for tor at oss-fuzz currently reuses clusterfuzz environment variables to compile dependencies. This has consequences when the dependencies themselves are upstream projects at oss-fuzz. The build environment sets the following flags to enable fuzzing of a target project: ``` CC=clang CXX=clang++ CFLAGS=-O1 -fno-omit-frame-pointer -gline-tables-only -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -fsanitize=address -fsanitize-address-use-after-scope -fsanitize=fuzzer-no-link CXXFLAGS=-O1 -fno-omit-frame-pointer -gline-tables-only -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -fsanitize=address -fsanitize-address-use-after-scope -fsanitize=fuzzer-no-link -stdlib=libc++ ``` In the case of zlib: Using the environment flags above as-is results in activating oss-fuzz instrumentation. Eventually resulting in ambiguously placed `undefined symbol __sancov_lowest_stack` because stack depth tracing was not instrumented properly. Which leads to a rabbit-hole of why are we fixing instrumenting fuzzers in tor's dependencies? Now Openssl also has an upstream clusterfuzz instance and so leaving the environment flags as-is also results in instrumenting openssl for oss-fuzz. This sounds wrong. If we're fuzzing tor then why are we also instrumenting dependencies for clusterfuzz? It looks like the dependencies **should** override these flags when built to avoid conflicts. When the flags are overridden to build debug dependencies, followed by building tor's fuzzers as usual, `check_build tor` passes all tests.