[PATCH] D20402: Try to fix libFuzzer running on Mac OSX

[Dan Liew via llvm-commits]

delcypher added a comment.

@kcc

> This is very, very sad. 

>  I intentionally made this thread local so that we don't use atomics in a very hot place (and malloc is often a very hot place).


Okay. My implementation isn't very good then

> Besides, I am only collecting counts from the main thread.


Okay, so that was intentional. So my implementation isn't just bad, it's also wrong. Is the reason you only want to collect counts from the main thread for the reason I gave in my earlier comment? Or is there another reason?

> Need to find another solution, e.g. to not touch AllocTracer before we called Start() on it.


Well there's a really hacky way to do that. There could be a global bool guarding access to `AllocTracer` that we set to true once we call ``Start()``. Not sure if that's ideal though as technically would could race on the global bool if there are multiple threads.

Just a side though. The LeakSanitizer currently doesn't work on Mac OSX. AFAICT it only works right now on Linux that is not Android on x86_64, aarch64 or MIPS (based on reading `compiler-rt/lib/lsan/lsan_common.h` where CAN_SANITIZE_LEAKS is set). Whether or not the CAN_SANITIZE_LEAKS macro was enabled (and consequently if leak sanitization can be performed) does not seem to be exposed in the Leak Sanitizer's interface. There is the `__lsan_is_turned_off()` function but that is not affected by the value of the CAN_SANITIZE_LEAKS macro. Ideally  LibFuzzer shouldn't try to do anything related to leak checking if the leak sanitizer is not actually functional. If `__lsan_is_turned_off()`` was fixed to respect CAN_SANITIZE_LEAKS we could guard some of the code in LibFuzzer that supports running the LeakSanitizer.


http://reviews.llvm.org/D20402