-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Tracking Issue for stabilizing the sanitizers (e.g., AddressSanitizer, LeakSanitizer, MemorySanitizer, ThreadSanitizer) #123615
Comments
@davidtwco and I would like to propose initially stabilizing AddressSanitizer and LeakSanitizer for the Tier 1 targets that support them. After stabilizing these sanitizers, the supported sanitizers will look like this--we'll keep this supported sanitizers table updated as we stabilize the sanitizers:
|
@rustbot label A-sanitizers |
|
The above is specifically regarding MSAN but I guess analogous concerns for ASAN at least. |
Do you have an example of when it would be need that |
I've been working on this for the past few days and have an early/draft implementation of a create that provides (safe) interfaces and FFI bindings for the sanitizers interfaces (see https://crates.io/crates/sanitizers and https://github.com/rcvalle/rust-crate-sanitizers). It currently reflects the current state of the sanitizers interfaces API and documentation, and I think the crate and the sanitizers interfaces themselves would benefit from some standardization of their API and documentation and is something I'd like to improve in the future. Any contributions are greatly appreciated!
Thanks for pointing this out! I don't know the answer for this yet, but I think we could definitely reserve the right to (as you suggested) implement additional/specific checks for Rust in the future, similarly to how we could improve these sanitizers generally, and these would not be classified as breaking changes but improvements. What do you think? |
There are issues with the entry for
|
I think what @briansmith is imagining is a scenario where a crate has cfgs for unstable sanitisers (which that crates supports on nightly), but because of those cfgs, the crate now has warnings on stable. On stable, these cfgs would never evaluate to |
Exactly. |
This allows msan detection to "just-work" whenever someone passes `-Zsanitizer=memory`. Users no longer need to do any `getrandom`-specific configuration. This will also continue working once rust-lang/rust#123615 is merged which stabilizes some sanitizers (but not MemorySanitizer). This is the approch taken by other low-level crates: - [`parking_lot_core`](https://github.com/Amanieu/parking_lot/blob/ca920b31312839013b4455aba1d53a4aede21b2f/core/build.rs) - [`crossbeam-utils`](https://github.com/crossbeam-rs/crossbeam/blob/00283fb1818174c25b02d7f1c883c5e19f8506a4/crossbeam-utils/build.rs#L42) The only downside is that this adds a build-script, but it's as small as possible, doesn't seem to impact build times, and is only a temporary workaround. Signed-off-by: Joe Richey <[email protected]>
This allows msan detection to "just-work" whenever someone passes `-Zsanitizer=memory`. Users no longer need to do any `getrandom`-specific configuration. This will also continue working once rust-lang/rust#123615 is merged which stabilizes some sanitizers (but not MemorySanitizer). This is the approch taken by other low-level crates: - [`parking_lot_core`](https://github.com/Amanieu/parking_lot/blob/ca920b31312839013b4455aba1d53a4aede21b2f/core/build.rs) - [`crossbeam-utils`](https://github.com/crossbeam-rs/crossbeam/blob/00283fb1818174c25b02d7f1c883c5e19f8506a4/crossbeam-utils/build.rs#L42) The only downside is that this adds a build-script, but it's as small as possible, doesn't seem to impact build times, and is only a temporary workaround. Signed-off-by: Joe Richey <[email protected]>
This allows msan detection to "just-work" whenever someone passes `-Zsanitizer=memory`. Users no longer need to do any `getrandom`-specific configuration. This will also continue working once rust-lang/rust#123615 is merged which stabilizes some sanitizers (but not MemorySanitizer). This is the approch taken by other low-level crates: - [`parking_lot_core`](https://github.com/Amanieu/parking_lot/blob/ca920b31312839013b4455aba1d53a4aede21b2f/core/build.rs) - [`crossbeam-utils`](https://github.com/crossbeam-rs/crossbeam/blob/00283fb1818174c25b02d7f1c883c5e19f8506a4/crossbeam-utils/build.rs#L42) The only downside is that this adds a build-script, but it's as small as possible, doesn't seem to impact build times, and is only a temporary workaround. Signed-off-by: Joe Richey <[email protected]>
This allows msan detection to "just-work" whenever someone passes `-Zsanitizer=memory`. Users no longer need to do any `getrandom`-specific configuration. This will also continue working once rust-lang/rust#123615 is merged, which stabilizes some sanitizers (but not MemorySanitizer). This is the approch taken by other low-level crates: - [`parking_lot_core`](https://github.com/Amanieu/parking_lot/blob/ca920b31312839013b4455aba1d53a4aede21b2f/core/build.rs) - [`crossbeam-utils`](https://github.com/crossbeam-rs/crossbeam/blob/00283fb1818174c25b02d7f1c883c5e19f8506a4/crossbeam-utils/build.rs#L42) The only downside is that this adds a build-script, but it's as small as possible, doesn't seem to impact build times, and is only a temporary workaround. --------- Signed-off-by: Joe Richey <[email protected]>
This is a tracking issue for stabilizing the sanitizers (e.g., AddressSanitizer, LeakSanitizer, MemorySanitizer, ThreadSanitizer). The original tracking issue for the sanitizers support for Rust is #39699. This is part of our work to organize and stabilize support for the sanitizers. (See our roadmap at https://hackmd.io/@rcvalle/S1Ou9K6H6.)
Steps
Unresolved Questions
Is there any concern or anything that the community would like to see implemented before their stabilization?
Implementation history
The text was updated successfully, but these errors were encountered: