Yes, we have a couple of tests there, which verify that our socket communication works. It seems there is one test which specifically opens a non-localhost socket (TCPListen0GetPort (*)), so I would bet it's that's the one the firewall is having problems with. Or, if you have a particularly paranoid firewall, it could be all of them.
I am not sure what would be the right solution here. Not having a single non-localhost is not good, but neither is annoying firewalls... pl (*) If you're looking at the test, the seemingly hardcoded address in it (10.10.12.3) is not the address the socket binds to, but the address of the peer we expect to connect to that socket. We open wildcard sockets when expecting non-local peers. On Thu, 2 Aug 2018 at 15:28, via lldb-dev <lldb-dev@lists.llvm.org> wrote: > > Windows Firewall popped a message that hosttests.exe was doing something > that the firewall decided to block. I just enabled lldb as a project in > my build last night, so I hadn't seen this before. I'm inclined to think > it's doing a local/remote communication thing, but I wouldn't expect it > to tickle the firewall. > > Thought I should check in with the experts on what's happening here. > Thanks, > --paulr > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
