[Lldb-commits] [lldb] [lldb][test] Add stack frame padding to fix flaky DIL array subscript test (PR #141738)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett updated https://github.com/llvm/llvm-project/pull/141738

>From ce1b2c86299944608569db2a2fa2403c8e9e2b3b Mon Sep 17 00:00:00 2001
From: David Spickett <david.spickett at linaro.org>
Date: Wed, 28 May 2025 10:15:42 +0000
Subject: [PATCH] [lldb][test] Fix flaky DIL array subscript test by recuding
 array indexes

This test has been flaky on Linaro's Windows on Arm bot and I was
able to reproduce it within 10 or so runs locally.

When it fails it's because we failed to read the value of int_arr[100].
When that happens the memory looks like this:
```
[0x0000006bf88fd000-0x0000006bf8900000) rw-      <-- sp (0x0000006bf88ffe20)
[0x0000006bf8900000-0x0000025fec900000) ---      <-- int_arr[100] (0x0000006bf8900070)
```
The first region is the stack and the stack pointer is pointing
within that region, as expected.

The second region is where we are trying to read int_arr[100] from
and this is not mapped because we're trying to read above the start
of the stack.

Sometimes the test passes I think because ASLR / DYNAMICBASE moves
the start of the stack down enough so there is some readable memory
at the top.

https://learn.microsoft.com/en-us/cpp/build/reference/dynamicbase?view=msvc-170

Note "Because ASLR can't be disabled on ARM, ARM64, or ARM64EC architectures,
/DYNAMICBASE:NO isn't supported for these targets.". Which means on this bot,
the layout is definitely being randomised.

We don't need to be testing indexes this large. So I've changed the two
test indexes to 3 (1 beyond the end) and 10 (a larger distance beyond the end).
We know that index 42 always worked on the bot, so 10 should be fine, and
did not fail locally.
---
 .../ArraySubscript/TestFrameVarDILArraySubscript.py      | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/lldb/test/API/commands/frame/var-dil/basics/ArraySubscript/TestFrameVarDILArraySubscript.py b/lldb/test/API/commands/frame/var-dil/basics/ArraySubscript/TestFrameVarDILArraySubscript.py
index 66f4c62761004..0d91f804ce565 100644
--- a/lldb/test/API/commands/frame/var-dil/basics/ArraySubscript/TestFrameVarDILArraySubscript.py
+++ b/lldb/test/API/commands/frame/var-dil/basics/ArraySubscript/TestFrameVarDILArraySubscript.py
@@ -19,8 +19,6 @@ def expect_var_path(self, expr, compare_to_framevar=False, value=None, type=None
             self.runCmd("settings set target.experimental.use-DIL true")
             self.assertEqual(value_dil.GetValue(), value_frv.GetValue())
 
-    # int_arr[100] sometimes points to above the stack region, fix coming soon.
-    @skipIfWindows
     def test_subscript(self):
         self.build()
         lldbutil.run_to_source_breakpoint(
@@ -53,9 +51,10 @@ def test_subscript(self):
         # Both typedefs and refs
         self.expect("frame var 'td_int_arr_ref[td_int_idx_1_ref]'", error=True)
 
-        # Test for index out of bounds.
-        self.expect_var_path("int_arr[42]", True, type="int")
-        self.expect_var_path("int_arr[100]", True, type="int")
+        # Test for index out of bounds. 1 beyond the end.
+        self.expect_var_path("int_arr[3]", True, type="int")
+        # Far beyond the end (but not far enough to be off the top of the stack).
+        self.expect_var_path("int_arr[10]", True, type="int")
 
         # Test address-of of the subscripted value.
         self.expect_var_path("*(&int_arr[1])", value="2")