DFSAN release_shadow_space.c is flaky #91287
Labels
Comments
|
@MaskRay : maybe you have thoughts on this? |
joker-eph
added a commit
to joker-eph/llvm-project
that referenced
this issue
May 8, 2024
The current pass rate on the bot is ~50%. llvm#91287
|
Seems fine to disable it now. I've seen it failed for unrelated patches. |
joker-eph
added a commit
that referenced
this issue
May 9, 2024
The current pass rate on the bot is ~50%. #91287
thurstond
added a commit
to thurstond/llvm-project
that referenced
this issue
Jun 6, 2024
This test case shows a limitation of DFSan's sscanf implementation (introduced in https://reviews.llvm.org/D153775): it simply ignores ordinary characters in the format string, instead of actually comparing them against the input. This may change the semantics of instrumented programs. Importantly, this also means that DFSan's release_shadow_space.c test, which relies on sscanf to scrape the RSS from /proc/maps output, will incorrectly match lines that don't contain RSS information. As a result, it is scraping numbers from irrelevant output (e.g., base addresses), and can therefore result in test flakiness (llvm#91287).
|
The reason for the failure is that DFSan's sscanf is ignoring ordinary characters in the format string. DFSan's release_shadow_space.c test relies on sscanf to scrape the RSS from /proc/maps output and is therefore scraping numbers from irrelevant output (e.g., base addresses), leading to test flakiness. I've added a test case that illustrates this: #94700 |
thurstond
added a commit
that referenced
this issue
Jun 7, 2024
This test case shows a limitation of DFSan's sscanf implementation (introduced in https://reviews.llvm.org/D153775): it simply ignores ordinary characters in the format string, instead of actually comparing them against the input. This may change the semantics of instrumented programs. Importantly, this also means that DFSan's release_shadow_space.c test, which relies on sscanf to scrape the RSS from /proc/maps output, will incorrectly match lines that don't contain RSS information. As a result, it adding together numbers from irrelevant output (e.g., base addresses), resulting in test flakiness (#91287).
thurstond
added a commit
to thurstond/llvm-project
that referenced
this issue
Jun 7, 2024
DFSan's sscanf is incorrect (llvm#94769), which results in erroneous matches when scraping RSS /proc/maps. This patch works around the issue by using strstr as a secondary check. It also adds a loose validity check for the initial RSS, to guard against future regressions in get_rss_kb(). Fixes llvm#91287
thurstond
added a commit
that referenced
this issue
Jun 8, 2024
DFSan's sscanf is incorrect (#94769), which results in erroneous matches when scraping RSS from /proc/maps. This patch works around the issue by using strstr as a secondary check. It also adds a loose validity check for the initial RSS measurement, to guard against regressions in get_rss_kb(). Fixes #91287
nekoshirro
pushed a commit
to nekoshirro/Alchemist-LLVM
that referenced
this issue
Jun 9, 2024
DFSan's sscanf is incorrect (llvm#94769), which results in erroneous matches when scraping RSS from /proc/maps. This patch works around the issue by using strstr as a secondary check. It also adds a loose validity check for the initial RSS measurement, to guard against regressions in get_rss_kb(). Fixes llvm#91287 Signed-off-by: Hafidz Muzakky <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For a few days, I see this test being flaky on the bot, here is an example run: https://lab.llvm.org/buildbot/#/builders/272/builds/15892
The text was updated successfully, but these errors were encountered: