[Lldb-commits] [lldb] [lldb-dap] Added "port" property to vscode "attach" command. (PR #91570)

[Pavel Labath via lldb-commits]

================
@@ -0,0 +1,142 @@
+"""
+Test lldb-dap "port" configuration to "attach" request
+"""
+
+
+import dap_server
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+from lldbsuite.test import lldbplatformutil
+import lldbgdbserverutils
+import lldbdap_testcase
+import os
+import shutil
+import subprocess
+import tempfile
+import threading
+import time
+import sys
+import socket
+
+
+class TestDAP_attachByPortNum(lldbdap_testcase.DAPTestCaseBase):
+    def get_free_port(self):
+        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
+        s.bind(("", 0))
+        port = s.getsockname()[1]
+        s.close()
+        return port
----------------
labath wrote:

Fair enough. Let me try to rephrase.

The thing I want to avoid is races in port allocation. Your current algorithm works like this:
1. open a socket
2. use it to get a free port (number) from the OS
3. close the socket
4. pass the port number to lldb-server
5. have lldb-server listen on that port
6. connect to that port

This algorithm is racy for two reasons. One, because somewhere between the steps 3 and 5, someone else could start listening on that port. The second is because there's no sequencing between steps 5 and 6. Even if noone claims that port, if lldb-server just happens to be slower for whatever reason (that tends to happen more than you'd think when you're running many tests in parallel), the test can attempt to connect to the port before it gets opened.

Now, compare this to the algorithm in test/API/tools/lldb-server/commandline/TestGdbRemoteConnection.py (test_named_pipe)
1. lldb-server opens a socket
2. lldb-server uses it to get a free port from the OS
3. lldb-server starts listening on the port
4. lldb-server sends the port number to the test (through the named pipe)
5. the test connects to that port

There's no race here. The socket that's used for getting the port number is the same that's used for listening for incoming connections, so there's no possibility for someone to snatch it from under us. And because the test has to wait for the port number before it can connect (and because the lldb-server does steps 3 and 4 in this order), we can be sure the lldb-server will be listening by the time we connect.

That's not the only way to implement these things, but my suggestion is to do this, because the code is already there, and it shouldn't be too hard to make it usable in your test as well.

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