[Sanitizer] Bump soft_rss_limit_mb in test #170911
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This test is failing on some buildbots now that the internal shell has been turned on and was failing previously on some ppc bots when turning it on a while back (before it got reverted). At least one X86 bot is barely hitting the limit (https://lab.llvm.org/buildbot/#/builders/174/builds/28487 224MB). The PPC bots were way over the limit at about 400-420MB, so bump the limit to 450MB to hopefully ensure the test is not flaky. This likely needs to be bumped due to changes in the process tree (now that we invoke things through python rather than a bash shell) with the enablement of the internal shell.
Member
|
@llvm/pr-subscribers-compiler-rt-sanitizer Author: Aiden Grossman (boomanaiden154) ChangesThis test is failing on some buildbots now that the internal shell has been turned on and was failing previously on some ppc bots when turning it on a while back (before it got reverted). At least one X86 bot is barely hitting the limit This likely needs to be bumped due to changes in the process tree (now that we invoke things through python rather than a bash shell) with the enablement of the internal shell. Full diff: https://github.com/llvm/llvm-project/pull/170911.diff 1 Files Affected:
diff --git a/compiler-rt/test/sanitizer_common/TestCases/Linux/soft_rss_limit_mb_test.cpp b/compiler-rt/test/sanitizer_common/TestCases/Linux/soft_rss_limit_mb_test.cpp
index e6fc22dc58d23..0a97fa64d6ec2 100644
--- a/compiler-rt/test/sanitizer_common/TestCases/Linux/soft_rss_limit_mb_test.cpp
+++ b/compiler-rt/test/sanitizer_common/TestCases/Linux/soft_rss_limit_mb_test.cpp
@@ -2,12 +2,12 @@
// RUN: %clangxx -O2 %s -o %t
//
// Run with limit should fail:
-// RUN: %env_tool_opts=soft_rss_limit_mb=220:quarantine_size=1:allocator_may_return_null=1 %run %t 2>&1 | FileCheck %s -check-prefix=CHECK_MAY_RETURN_1
-// RUN: %env_tool_opts=soft_rss_limit_mb=220:quarantine_size=1:allocator_may_return_null=0 not %run %t 2>&1 | FileCheck %s -check-prefix=CHECK_MAY_RETURN_0 --implicit-check-not="returned null"
+// RUN: %env_tool_opts=soft_rss_limit_mb=450:quarantine_size=1:allocator_may_return_null=1 %run %t 2>&1 | FileCheck %s -check-prefix=CHECK_MAY_RETURN_1
+// RUN: %env_tool_opts=soft_rss_limit_mb=450:quarantine_size=1:allocator_may_return_null=0 not %run %t 2>&1 | FileCheck %s -check-prefix=CHECK_MAY_RETURN_0 --implicit-check-not="returned null"
// This run uses getrusage. We can only test getrusage when allocator_may_return_null=0
// because getrusage gives us max-rss, not current-rss.
-// RUN: %env_tool_opts=soft_rss_limit_mb=220:quarantine_size=1:allocator_may_return_null=0:can_use_proc_maps_statm=0 not %run %t 2>&1 | FileCheck %s -check-prefix=CHECK_MAY_RETURN_0 --implicit-check-not="returned null"
+// RUN: %env_tool_opts=soft_rss_limit_mb=450:quarantine_size=1:allocator_may_return_null=0:can_use_proc_maps_statm=0 not %run %t 2>&1 | FileCheck %s -check-prefix=CHECK_MAY_RETURN_0 --implicit-check-not="returned null"
// REQUIRES: stable-runtime
// Ubsan does not intercept pthread_create.
|
🐧 Linux x64 Test Results
✅ The build succeeded and all tests passed. |
petrhosek
approved these changes
Dec 8, 2025
Collaborator
|
@boomanaiden154 I'm still seeing intermittent failures after this change unfortunately. Should we bump the limit up even further?
|
honeygoyal
pushed a commit
to honeygoyal/llvm-project
that referenced
this pull request
Dec 9, 2025
This test is failing on some buildbots now that the internal shell has been turned on and was failing previously on some ppc bots when turning it on a while back (before it got reverted). At least one X86 bot is barely hitting the limit (https://lab.llvm.org/buildbot/#/builders/174/builds/28487 224MB-235MB). This likely needs to be bumped due to changes in the process tree (now that we invoke things through python rather than a bash shell) with the enablement of the internal shell.
Contributor
Author
|
I bumped the limit to 384 and that seems to have improved things. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This test is failing on some buildbots now that the internal shell has been turned on and was failing previously on some ppc bots when turning it on a while back (before it got reverted).
At least one X86 bot is barely hitting the limit
(https://lab.llvm.org/buildbot/#/builders/174/builds/28487 224MB-235MB).
This likely needs to be bumped due to changes in the process tree (now that we invoke things through python rather than a bash shell) with the enablement of the internal shell.