1589839 - TSan: libFuzzer instrumentation for rust code causes races on coverage counters without showing the global name

Status: RESOLVED WONTFIX

(Core :: General, defect)

Description

[Christian Holler (:decoder)]

Attachment: tsan-rust-libfuzzer-a43ad34ac8e3.txt

Attached is an example for a race showing up under the following conditions:

1. The Rust code has been compiled with TSan

2. The Rust code has been compiled with sanitizer coverage (e.g. through --enable-fuzzing)

In C++ code, the same races show up, but they show up properly racing on globals that match the name .L__sancov_gen_ and we have suppressed those already. For some reason, the name is not showing up in Rust code but I confirmed that sanitizer coverage is causing this by disabling it for Rust code.

From my perspective we have three options to move forward here:

1. Disable sanitizer coverage for Rust code in TSan builds

2. Figure out why the global variable name is not showing up and fixing that (so the suppression matches properly)

3. Making the sanitizer coverage globals optionally atomic in TSan builds (involves changing Clang). Of course atomic variables would cause a slowdown, but so do suppressions. Frequent races caught by suppressions cause massive slowdown which might well be larger than the use of atomic variables.

For unblocking fuzzing with TSan, going for option 1) might be a good short term solution until either 2) or 3) can happen.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:sdetar, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Christian Holler (:decoder)]

In bug 1592250 we disabled libFuzzer coverage instrumentation for TSan because according to :kcc, this is not meant to work together (for now). So I'm going ahead and close this bug as wontfix. We can revisit adding the instrumentation back when the sanitizer developers decide to make the coverage feature race-free.