[libc++][lldb-dap][test] Fix CI for bootstrapping-build

[frederick-vs-ja]

#140107 changed the default argument of disableASLR of related functions from False to True. libc++ CI has been stably failing for TestDAP_subtleFrames.py (in bootstrapping-build) since then. The error message "personality set failed: Operation not permitted" seems related to ASLR.

This PR attempts to fix the CI failure by changing the default value of disableASLR in dap_server.py to False.

[llvmbot]

@llvm/pr-subscribers-lldb

@llvm/pr-subscribers-libcxx

Author: A. Jiang (frederick-vs-ja)

Changes

It seem that #140107 changed the default argument of disableASLR of related functions from False to True. libc++ CI has been stably failing for TestDAP_subtleFrames.py (in bootstrapping-build) since then. The error message "personality set failed: Operation not permitted" seems related to ASLR.

This PR attempts to fix the CI failure.

---

Full diff: https://github.com/llvm/llvm-project/pull/141543.diff

2 Files Affected:

• (modified) libcxx/include/__config (+2)
• (modified) lldb/test/API/tools/lldb-dap/stackTrace/subtleFrames/TestDAP_subtleFrames.py (+1-1)

diff --git a/libcxx/include/__config b/libcxx/include/__config
index 57223e4f1db18..49abe17a4da76 100644
--- a/libcxx/include/__config
+++ b/libcxx/include/__config
@@ -1219,3 +1219,5 @@ typedef __char32_t char32_t;
 #endif // __cplusplus
 
 #endif // _LIBCPP___CONFIG
+
+// Just for CI, will be reverted.
diff --git a/lldb/test/API/tools/lldb-dap/stackTrace/subtleFrames/TestDAP_subtleFrames.py b/lldb/test/API/tools/lldb-dap/stackTrace/subtleFrames/TestDAP_subtleFrames.py
index 1e41e841e39bc..1751c52072aac 100644
--- a/lldb/test/API/tools/lldb-dap/stackTrace/subtleFrames/TestDAP_subtleFrames.py
+++ b/lldb/test/API/tools/lldb-dap/stackTrace/subtleFrames/TestDAP_subtleFrames.py
@@ -17,7 +17,7 @@ def test_subtleFrames(self):
         Internal stack frames (such as the ones used by `std::function`) are marked as "subtle".
         """
         program = self.getBuildArtifact("a.out")
-        self.build_and_launch(program)
+        self.build_and_launch(program, disableASLR=False)
         source = "main.cpp"
         self.set_source_breakpoints(source, [line_number(source, "BREAK HERE")])
         self.continue_to_next_stop()

[frederick-vs-ja]

There're many TSan and MSan errors seemingly related to ASLR. But it's curious that how did they happen when TestDAP_subtleFrames.py hasn't been executed.

[Michael137]

I'm a bit confused why this test is special and would be the only one manually setting disableASLR=False. I changed the default in #113593

@JDevlieghere @ashgti why did we switch the default back to disableASLR=False?

[Michael137]

Looks like #140107 refactored this stuff and as @frederick-vs-ja points out, my fix in #113593 essentially got reverted. @ashgti is there some default config for tests that we could stick disableASLR=False into?

[frederick-vs-ja]

I'm a bit confused why this test is special and would be the only one manually setting disableASLR=False. I changed the default in #113593

Would it be a good idea to change here instead in order to restore disableASLR=False?

llvm-project/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py

Lines 409 to 417 in bf6cd24

	def launch(
	self,
	program=None,
	*,
	sourceInitFile=False,
	disconnectAutomatically=True,
	expectFailure=False,
	**kwargs,
	):

[ashgti]

Maybe we should update https://github.com/llvm/llvm-project/blob/ff7bb17c88328276323603809d5d4549ca8bd22b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py#L859C9-L859C20 to default to False instead of True?

[Michael137]

Maybe we should update https://github.com/llvm/llvm-project/blob/ff7bb17c88328276323603809d5d4549ca8bd22b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py#L859C9-L859C20 to default to False instead of True?

Yea i think that's the best way forward

[ldionne]

I'm going to land this to attempt to unbreak libc++'s CI, which is in a really bad shape right now. From the comments above, this seems to have consensus to move forward.

[ldionne]

Thanks a lot for investigating this folks, in particular @frederick-vs-ja for jumping on the issue to restore libc++'s CI.