I didn't see the test deleted upstream (perhaps you forgot to run `git push`?) so I removed it in 5b8e4a11029ff169fdac7caa3c7aa211f318adf6.
On Mon, Nov 23, 2020 at 10:51 AM Jonas Devlieghere <jo...@devlieghere.com> wrote: > I'm OOO this week but I've deleted the test until I can write a better one > next week. > > On Mon, Nov 23, 2020 at 5:21 AM Pavel Labath <pa...@labath.sk> wrote: > >> On 14/11/2020 02:39, Jonas Devlieghere via lldb-commits wrote: >> > +# RUN: echo -e 'platform select remote-gdb-server\nprocess connect >> connect://localhost:4321' | %lldb 2>&1 | FileCheck %s >> > + >> > +# CHECK: Platform: remote-gdb-server >> > +# CHECK: Connected: no >> > +# CHECK: error: Failed to connect port >> >> This is a bad test. You can't assume that the host machine will not have >> port 4321 open. If it does, for some reason, the test will fail. >> Moreover, if that port happens to belong to some other test (not likely, >> as we normally use higher port numbers, but possible), the spurious >> connection cause *that* test to fail as well... >> >> (We've observed flakyness in this test internally. While I don't have >> conclusive proof that this is the cause, it's a pretty good bet that it >> is.) >> >> The right way to handle this would be to first claim a port, and then >> have lldb server connect to that port. (most likely requires writing the >> test in python.) >> >> pl >> >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
