Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make tests fail if ASan finds an errors #10005

Merged
merged 1 commit into from
Mar 7, 2022

Conversation

hahnjo
Copy link
Member

@hahnjo hahnjo commented Mar 2, 2022

The AddressSanitizer also loads the LeakSanitizer flags and even though the documentation suggests that exitcode can be set per sanitizer, this doesn't appear to be the case and our tests exit with code 0 after the AddressSanitizer found a problem. After this change, around 100 tests will fail due to several issues.

The AddressSanitizer also loads the LeakSanitizer flags and even though
the documentation suggests that exitcode can be set per sanitizer, this
doesn't appear to be the case and our tests exit with code 0 after the
AddressSanitizer found a problem. After this change, around 100 tests
will fail due to several issues.
@hahnjo hahnjo requested a review from hageboeck March 2, 2022 07:41
@hahnjo hahnjo self-assigned this Mar 2, 2022
@phsft-bot
Copy link
Collaborator

Starting build on ROOT-debian10-i386/cxx14, ROOT-performance-centos8-multicore/default, ROOT-ubuntu16/nortcxxmod, ROOT-ubuntu2004/soversion, mac1015/python3, mac11/cxx17, windows10/cxx14
How to customize builds

@hageboeck
Copy link
Member

I find this surprising; it used to affect only lsan when this was implemented. I trust that you verified this, though.

The only other thing I can say is that maybe now it's a good idea to verify whether it's possible to switch on leak sanitizer. With llvm 5, this just wasn't possible, and JITted functions also created problems because their memory management escaped asan. That's why the exitcode was hardcoded to 0. Maybe you can switch it on once, and see how much explodes.

@hageboeck
Copy link
Member

@phsft-bot build only on ROOT-ubuntu2004-clang with flags -Dasan=ON

@phsft-bot
Copy link
Collaborator

Starting build on ROOT-debian10-i386/cxx14, ROOT-performance-centos8-multicore/default, ROOT-ubuntu16/nortcxxmod, ROOT-ubuntu2004/soversion, mac1015/python3, mac11/cxx17, windows10/cxx14
How to customize builds

@hageboeck
Copy link
Member

@phsft-bot build just on ROOT-ubuntu2004-clang with flags -Dasan=ON

@hahnjo
Copy link
Member Author

hahnjo commented Mar 2, 2022

I find this surprising; it used to affect only lsan when this was implemented. I trust that you verified this, though.

Yes, the relevant code is https://github.com/llvm/llvm-project/blob/7f99e1870f776a25e03526e3190105c094750d98/compiler-rt/lib/asan/asan_flags.cpp#L113-L116 which AFAICT has been the case basically since it was introduced by llvm/llvm-project@1b73bde. Now it's possible that earlier toolchains on macOS did not have CAN_SANITIZE_LEAKS...

The only other thing I can say is that maybe now it's a good idea to verify whether it's possible to switch on leak sanitizer. With llvm 5, this just wasn't possible, and JITted functions also created problems because their memory management escaped asan. That's why the exitcode was hardcoded to 0. Maybe you can switch it on once, and see how much explodes.

That's another thing that deviates from the documentation: LSan is supposed to be on-by-default with ASan on Linux x86, but it's not for us...

@hageboeck
Copy link
Member

That's another thing that deviates from the documentation: LSan is supposed to be on-by-default with ASan on Linux x86, but it's not for us...

It's off intentionally because of what I wrote previously.

#ifdef ASAN_DETECT_LEAKS
#define DETECT_LEAKS ":detect_leaks=1"
#else
#define DETECT_LEAKS ":detect_leaks=0"
#endif

@hageboeck
Copy link
Member

The matrix whitelist doesn't allow selecting the node that's running asan in the nightlies.
https://github.com/root-project/jenkins-pipelines/blob/8a7cb74059e70c550a70691f4c7c2d6fff8f0fc9/src/cern/root/pipeline/BuildConfiguration.groovy#L11-L35

Maybe ubuntu19 ist still there?

@hageboeck
Copy link
Member

@phsft-bot build just on ROOT-ubuntu1904-clang with flags -Dasan=ON

@hahnjo
Copy link
Member Author

hahnjo commented Mar 2, 2022

It's off intentionally because of what I wrote previously.

#ifdef ASAN_DETECT_LEAKS
#define DETECT_LEAKS ":detect_leaks=1"
#else
#define DETECT_LEAKS ":detect_leaks=0"
#endif

Ah yes, I only checked __lsan_options...

Regarding the test failures, I'm currently going through them one-by-one to create issues on GitHub.

@hageboeck
Copy link
Member

Here's the culprit:
llvm/llvm-project@bb79b06

@hahnjo
Copy link
Member Author

hahnjo commented Mar 2, 2022

Here's the culprit: llvm/llvm-project@bb79b06

Sigh. That's even older than the commit linked above, but the documentation for LSan flags hasn't been updated since...

@hageboeck
Copy link
Member

@phsft-bot build just on ROOT-ubuntu2004-clang with flags -Dasan=ON

@hageboeck
Copy link
Member

@phsft-bot build just on ROOT-ubuntu2004-clang/default with flags -Dasan=ON

@phsft-bot
Copy link
Collaborator

Starting build on ROOT-ubuntu2004-clang/default with flags -Dasan=ON
How to customize builds

@hahnjo
Copy link
Member Author

hahnjo commented Mar 3, 2022

Build failed on ROOT-ubuntu2004-clang/default. Running on root-ubuntu-2004-1.cern.ch:/home/sftnight/build/workspace/root-pullrequests-build See console output.

Failing tests:

[...]

Yes, as expected many tests are failing now, so we have to decide on a strategy here: Do we want to fix all issues first or merge this one first to make it easier to debug things? I'm definitely in favor of the latter, it's a waste of time to check the verbose output of 30+ tests by hand because they're not failing if the Address Sanitizer found something...

@Axel-Naumann
Copy link
Member

We need to have everyone aboard for this, to fix it within two days not two months. We will discuss on Monday during the team meeting.

@hageboeck
Copy link
Member

Yes, as expected many tests are failing now, so we have to decide on a strategy here: Do we want to fix all issues first or merge this one first to make it easier to debug things?

I'd merge it as well. The build will be red for weeks or months, but the shifter should have a look and ping people every once in a while.
Given that it only runs during the night, you could even log in to the node and play with the last nightly build if you cannot reproduce the error.

@pcanal
Copy link
Member

pcanal commented Mar 4, 2022

@phsft-bot build just on ROOT-ubuntu2004-clang/default with flags -Dasan=ON

@phsft-bot
Copy link
Collaborator

Starting build on ROOT-ubuntu2004-clang/default with flags -Dasan=ON
How to customize builds

@hahnjo hahnjo merged commit b6be38f into root-project:master Mar 7, 2022
@hahnjo hahnjo deleted the asan-exitcode branch March 7, 2022 16:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants