On Thu, 26 Apr 2018 at 22:58, Leonard Mosescu via lldb-dev < lldb-dev@lists.llvm.org> wrote:
> I just did a clean build (debug) on Linux, and I noticed that the LLDB tests seem to consistently get stuck: > -- Testing: 1002 tests, 12 threads -- > 99% [==========================================================================================================================================-] ETA: 00:00:01 > lldb-Suite :: types/TestIntegerTypes.py > At this point there are a bunch of llvm-lit processes waiting and two suspicious LLDB unit tests: > ProcessGdbRemoteTests --gtest_filter=GDBRemoteCommunicationClientTest.GetMemoryRegionInfo > ProcessGdbRemoteTests --gtest_filter=GDBRemoteCommunicationClientTest.GetMemoryRegionInfoInvalidResponse > I took a quick look and they both seem to blocked on communicating with the remote: > thread #2, name = 'ProcessGdbRemot', stop reason = signal SIGSTOP These tests should have two threads communicating with each other. Can you check what the other thread is doing? My bet would be that fact that we are now running dotest tests concurrently with the unittests is putting more load on the system (particularly in debug builds), and the communication times out. You can try increasing the timeout in GDBRemoteTestUtils.cpp:GetPacket to see if that helps. _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
