-
Notifications
You must be signed in to change notification settings - Fork 770
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
Run tests with address sanitizer on CI #2688
Conversation
For rust-numpy, I eventually switched over to Valgrind's memcheck instead. It is much slower, but it also has better coverage as it does not rely on compiler-generated instrumentation, i.e. it will also cover the CPython code we interact with in addition to our own code. (I suspect that there are bugs which are only apparent when both sides are considered, e.g. when the allocation happens on the CPython side does not get the necessary ASAN metadata attached.) |
Valgrind does not finish in |
We should definitely run the sanitizer tests in release mode as a lot of issues in FFI interactions only come to light with optimizations applied as otherwise stack space is not reused as aggressively for example. As for why it did not uncover #2687, I think that is due no actual invalid memory accesses happening. Or put differently, ASAN did not catch that either. I think this is due to building the standard library with debug assertions enabled which asserts non-null pointers for I think it would be useful to do both: Always have a pass with (A benefit of Valgrind for rust-numpy was that it was able to check the doctests in addition to the unit tests. The doctests failed to compile using the usual ASAN-via-RUSTFLAGS approach.) |
Make sense, thanks for the detailed explanation @adamreichold |
For rust-numpy, I decided for separate CI jobs using Valgrind and cargo-careful which appears to be the best compromise between coverage and simplicity to me at the moment: PyO3/rust-numpy#355 |
No description provided.