Closed randomshinichi closed 6 years ago
Instead of using AddressSanitizer in this fashion, we could investigate this instead:
// -msan
// enable interoperation with memory sanitizer.
// Supported only on linux/amd64, linux/arm64
// and only with Clang/LLVM as the host C compiler.
Funnily enough this extra, important piece of info seems to appear and disappear, and it is not in go version 1.10.
The problem:
It turns out that if you run
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.4 go test -v ./pkg/core/block
then it will fail to compile. Notice the g++ failed: exit status 1. This means that the compilation step failed.To get the tests, you have to compile the package in a separate step:
go test -c -v ./pkg/core/block
. This will produce an executableblock.test
.If you compiled goqryptonight with ASAN, you need to run
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.4 ./block.test
otherwise it will fail with this error:==7847==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
Since there is no way to specify that LD_PRELOAD should NOT be set during compilation but should be set during test running within go-test, the best thing to do is just disable AddressSanitizer for goqryptonight. Perhaps AddressSanitizer should only be used within goqryptonight tests, not in tests for other components that depend on goqryptonight.
Explanation: compilation probably fails because leaks were detected within ld/gcc itself. The following stack trace shows that none of the leak reports actually mentioned our code.
This is what happens when you go LD_PRELOAD go test -v ./... - even fails at AddressState: