<div dir="ltr">I'm OOO this week but I've deleted the test until I can write a better one next week. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 23, 2020 at 5:21 AM Pavel Labath <<a href="mailto:pavel@labath.sk">pavel@labath.sk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On 14/11/2020 02:39, Jonas Devlieghere via lldb-commits wrote:<br>
> +# RUN: echo -e 'platform select remote-gdb-server\nprocess connect connect://localhost:4321' | %lldb 2>&1 | FileCheck %s<br>
> +<br>
> +# CHECK: Platform: remote-gdb-server<br>
> +# CHECK: Connected: no<br>
> +# CHECK: error: Failed to connect port<br>
<br>
This is a bad test. You can't assume that the host machine will not have <br>
port 4321 open. If it does, for some reason, the test will fail. <br>
Moreover, if that port happens to belong to some other test (not likely, <br>
as we normally use higher port numbers, but possible), the spurious <br>
connection cause *that* test to fail as well...<br>
<br>
(We've observed flakyness in this test internally. While I don't have <br>
conclusive proof that this is the cause, it's a pretty good bet that it is.)<br>
<br>
The right way to handle this would be to first claim a port, and then <br>
have lldb server connect to that port. (most likely requires writing the <br>
test in python.)<br>
<br>
pl<br>
</blockquote></div>