[all-commits] [llvm/llvm-project] 8cc49b: [lldb] Use reverse connection method for lldb-serv...

[Pavel Labath via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 8cc49bec2e067808e4b4d091a351fd66616d7b18
      https://github.com/llvm/llvm-project/commit/8cc49bec2e067808e4b4d091a351fd66616d7b18
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2020-10-29 (Thu, 29 Oct 2020)

  Changed paths:
    M lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
    A lldb/test/API/tools/lldb-server/commandline/TestGdbRemoteConnection.py
    R lldb/test/API/tools/lldb-server/commandline/TestStubReverseConnect.py

  Log Message:
  -----------
  [lldb] Use reverse connection method for lldb-server tests

This fixes an flakyness is all gdb-remote tests. These tests have been
(mildly) flaky since we started using "localhost" instead of 127.0.0.1
in the test suite. The reason is that lldb-server needs to create two
sockets (v4 and v6) to listen for localhost connections. The algorithm
it uses first tries to select a random port (bind(localhost:0)) for the
first address, and then bind the same port for the second one.

The creating of the second socket can fail as there's no guarantee that
port will be available -- it seems that the (linux) kernel tries to
choose an unused port for the first socket (I've had to create thousands
of sockets to reproduce this reliably), but this can apparantly fail
when the system is under load (and our test suite creates a _lot_ of
sockets).

The socket creationg operation is considered successful if it creates at
least one socket is created, but the test harness has no way of knowing
which one it is, so it can end up connecting to the wrong address.

I'm not aware of a way to atomically create two sockets bound to the
same port. One way to fix this would be to make lldb-server report the
address is it listening on instead of just the port. However, this would
be a breaking change and it's not clear to me that's worth it (the
algorithm works pretty well under normal circumstances).

Instead, this patch sidesteps that problem by using "reverse"
connections. This way, the test harness is responsible for creating the
listening socket so it can pass the address that it has managed to open.
It also results in much simpler code overall.

To preserve test coverage for the named pipe method, I've moved the
relevant code to a dedicated test. To avoid original problem, this test
passes raw addresses (as obtained by getaddrinfo(localhost)) instead of
"localhost".

Differential Revision: https://reviews.llvm.org/D90313