Bug 1447423

Summary:	Enable Rust sanitizers
Product:	[Fedora] Fedora	Reporter:	Josh Stone <jistone>
Component:	rust	Assignee:	Rust SIG <rust-sig>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	igor.raits, jistone, rust-sig, TicoTimo
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	x86_64
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-08-29 20:43:05 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Josh Stone 2017-05-02 17:12:16 UTC

Rust on x86_64-unknown-linux-gnu has some preliminary support for sanitizers, per this tracking issue: https://github.com/rust-lang/rust/issues/39699

- asan = AddressSanitizer
- lsan = LeakSanitizer
- msan = MemorySanitizer
- tsan = ThreadSanitizer

They need to be turned on with "./configure --enable-sanitizers".  This uses LLVM's cmake, which means we'll also need a BuildReq on cmake and llvm-static.  And the latter means I'll only want to do this with LLVM 3.9+ where we can force it to still link dynamically to libLLVM.so. (So not on F24.)

I thought at first that we'd want to isolate these in a subpackage, because the upstream librustc_?san*.rlib binaries are about 60MB, but once you strip debuginfo they're only 8MB.  That's manageable, but still a relatively large addition to the current 31MB rust-std-static.  Given the niche use, it may still make sense to package them separately.

Comment 1 Josh Stone 2017-05-05 04:03:53 UTC

Currently, you have to use an unstable -Z option, like -Zsanitizer=asan.  This warns that such options are only meant for the nightly compiler, currently accepted for compatibility but will "soon" change.  It's been a long time coming, but this was finally blocked on all but nightly:
https://github.com/rust-lang/rust/pull/41751

I think we should wait for sanitizers to stabilize before packaging them.

Comment 2 wibrown@redhat.com 2017-05-05 05:32:03 UTC

do you have an estimate as to what kind of time frame that would be before they stabilise? Thanks for your work on this mate :)

Comment 3 Josh Stone 2017-05-05 16:58:40 UTC

There's no indication that they're considering stabilization anytime soon. :/
I'll ask on the GH issue though.

FWIW, my local test at enabling this did appear to build just fine, though I didn't try using it.  But I'd hate to start shipping something that will become inaccessible once 1.19 ships with disabled -Z.

In the meantime, can you incorporate rust-nightly into your workflow?  It's pretty easy using rustup, and you can still prefer the system compiler like:

$ rustup toolchain link system /usr
$ rustup default system

Then you can use "rustup override" to target nightly for a particular directory, or switch toolchains in ad hoc commands like "cargo +nightly build".

Comment 4 Jan Kurik 2017-08-15 07:01:34 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 5 Josh Stone 2022-08-29 20:43:05 UTC

I'm deferring this to the upstream issue. If/when the feature stabilizes, we can ship it in the distro too.