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