[Lldb-commits] [lldb] Fix a bug with cancelling "attach -w" after you have run a process previously (PR #65822)

[David Spickett via lldb-commits]

================
@@ -127,3 +128,65 @@ def tearDown(self):
 
         # Call super's tearDown().
         TestBase.tearDown(self)
+                
+    def test_run_then_attach_wait_interrupt(self):
+        # Test that having run one process doesn't cause us to be unable
+        # to interrupt a subsequent attach attempt.
+        self.build()
+        exe = self.getBuildArtifact(exe_name)
+
+        target = lldbutil.run_to_breakpoint_make_target(self, exe_name, True)
+        launch_info = target.GetLaunchInfo()
+        launch_info.SetArguments(["q"], True)
+        error = lldb.SBError()
+        target.Launch(launch_info, error)
+        self.assertSuccess(error, "Launched a process")
+        self.assertState(target.process.state, lldb.eStateExited, "and it exited.") 
+        
+        # Okay now we've run a process, try to attach/wait to something
+        # and make sure that we can interrupt that.
+        
+        options = lldb.SBCommandInterpreterRunOptions()
+        options.SetPrintResults(True)
+        options.SetEchoCommands(False)
+
+        self.stdin_path = self.getBuildArtifact("stdin.txt")
+
+        with open(self.stdin_path, "w") as input_handle:
+            input_handle.write("process attach -w -n noone_would_use_this_name\nquit")
+
+        # Python will close the file descriptor if all references
+        # to the filehandle object lapse, so we need to keep one
+        # around.
+        self.filehandle = open(self.stdin_path, "r")
+        self.dbg.SetInputFileHandle(self.filehandle, False)
+
+        # No need to track the output
+        self.stdout_path = self.getBuildArtifact("stdout.txt")
+        self.out_filehandle = open(self.stdout_path, "w")
+        self.dbg.SetOutputFileHandle(self.out_filehandle, False)
+        self.dbg.SetErrorFileHandle(self.out_filehandle, False)
+
+        n_errors, quit_req, crashed = self.dbg.RunCommandInterpreter(
+            True, True, options, 0, False, False)
+        
+        while 1:
+            time.sleep(1)
+            if target.process.state == lldb.eStateAttaching:
+                break
+
+        self.dbg.DispatchInputInterrupt()
+        self.dbg.DispatchInputInterrupt()
+
+        self.out_filehandle.flush()
+        reader = open(self.stdout_path, "r")
+        results = reader.readlines()
+        found_result = False
+        for line in results:
+            if "Cancelled async attach" in line:
+                found_result = True
+                break
+        self.assertTrue(found_result, "Found async error in results")
----------------
DavidSpickett wrote:

This fails if `results` is empty.
```
********************************
[]
********************************
FAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: test_run_then_attach_wait_interrupt (TestProcessAttach.ProcessAttachTestCase)
<bound method SBProcess.Kill of SBProcess: pid = 0, state = exited, threads = 0, executable = ProcessAttach>: success

Restore dir to: /home/david.spickett/build-llvm-aarch64
======================================================================
FAIL: test_run_then_attach_wait_interrupt (TestProcessAttach.ProcessAttachTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/david.spickett/llvm-project/lldb/test/API/commands/process/attach/TestProcessAttach.py", line 195, in test_run_then_attach_wait_interrupt
    self.assertTrue(found_result, "Found async error in results")
AssertionError: False is not True : Found async error in results
Config=aarch64-/home/david.spickett/build-llvm-aarch64/bin/clang
----------------------------------------------------------------------
```
When the test works the results contain:
```
********************************
['error: attach failed: Cancelled async attach.\n', '\n', '... Interrupted.\n']
********************************
```
Running it in a loop it took ~40 runs to get a failing one.

I wonder if that is because the attach happens to finish a lot faster sometimes, so there's no time to cancel it? If that's down to the OS and machine load, I'm not sure how we'd make this predictable.

The ugly option is to say if the results are empty, pass the test and assume the other 39 runs will check for the bug.

https://github.com/llvm/llvm-project/pull/65822