This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Use reverse connection method for lldb-server tests
ClosedPublic

Authored by labath on Oct 28 2020, 8:14 AM.

Details

Summary

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".

Diff Detail

Event Timeline

labath created this revision.Oct 28 2020, 8:14 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 28 2020, 8:14 AM
Herald added a subscriber: jfb. · View Herald Transcript
labath requested review of this revision.Oct 28 2020, 8:14 AM

On GreenDragon we've also noticed the increased flakiness and it sounds like it could very well be the same issue? It seems like this would only solve it for lldb-server, while we run these tests with debugserver. The latter doesn't support --reverse-connect, so I'm wondering if there's something else we can do to solve the flakiness for both? Should we just return to using 127.0.0.1?

On GreenDragon we've also noticed the increased flakiness and it sounds like it could very well be the same issue? It seems like this would only solve it for lldb-server, while we run these tests with debugserver. The latter doesn't support --reverse-connect, so I'm wondering if there's something else we can do to solve the flakiness for both? Should we just return to using 127.0.0.1?

It does support --reverse-connect, and I've checked that this works with it. The only tricky part is that the option does not show up in its --help output. (it didn't used to show for lldb-server either, that's why I did the libOption patch :P).

JDevlieghere accepted this revision.Oct 28 2020, 9:15 AM

On GreenDragon we've also noticed the increased flakiness and it sounds like it could very well be the same issue? It seems like this would only solve it for lldb-server, while we run these tests with debugserver. The latter doesn't support --reverse-connect, so I'm wondering if there's something else we can do to solve the flakiness for both? Should we just return to using 127.0.0.1?

It does support --reverse-connect, and I've checked that this works with it. The only tricky part is that the option does not show up in its --help output. (it didn't used to show for lldb-server either, that's why I did the libOption patch :P).

Haha, it feels like you read my mind because that's exactly what I checked. Now the pieces are falling in place ;-) LGTM!

This revision is now accepted and ready to land.Oct 28 2020, 9:15 AM
This revision was landed with ongoing or failed builds.Oct 29 2020, 5:50 AM
This revision was automatically updated to reflect the committed changes.
lldb/test/API/tools/lldb-server/commandline/TestGdbRemoteConnection.py