================
@@ -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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to