PS. just a wild guess, could it be related to : rL327970: Re-land: [lldb] Use vFlash commands when writing to target's flash memory… ?
On Tue, May 1, 2018 at 1:24 PM, Leonard Mosescu <mose...@google.com> wrote: > Thanks Pavel. It doesn't look like a timeout to me: > > 1. First, the other (main) thread is just waiting on the > std::future::get() on the final EXPECT_TRUE(result.get().Success()) > > *#0 0x00007fe4bdfbb6cd in pthread_join (threadid=140620333614848, > thread_return=0x0) at pthread_join.c:90* > *...* > *#14 0x000055b855bdf370 in std::future<lldb_private::Status>::get > (this=0x7ffe4498aad0) at /usr/include/c++/7/future:796* > *#15 0x000055b855b8c502 in > GDBRemoteCommunicationClientTest_GetMemoryRegionInfo_Test::TestBody > (this=0x55b85bc195d0)* > * at > /usr/local/google/home/mosescu/extra/llvm/src/tools/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp:* > 330 > > > 2. The part that seems interesting to me is this part of the callstack I > mentioned: > > * frame #9: 0x0000564647c39a23 > ProcessGdbRemoteTests`lldb_private::process_gdb_remote::GDBRemoteClientBase::SendPacketAndWaitForResponse(this=0x000056464d53e580, > payload=(Data = "qSupported:xmlRegisters=i386,arm,mips", Length = 37), > response=0x00007f2d1eb0a0e0, send_async=false) at > GDBRemoteClientBase.cpp:176* > * frame #10: 0x0000564647c44e0a > ProcessGdbRemoteTests`lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::GetRemoteQSupported(this=0x000056464d53e580) > at GDBRemoteCommunicationClient.cpp:370* > * frame #11: 0x0000564647c4427b > ProcessGdbRemoteTests`lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::GetQXferMemoryMapReadSupported(this=0x000056464d53e580) > at GDBRemoteCommunicationClient.cpp:200* > * frame #12: 0x0000564647c4c661 > ProcessGdbRemoteTests`lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::LoadQXferMemoryMap(this=0x000056464d53e580) > at GDBRemoteCommunicationClient.cpp:1609* > * frame #13: 0x0000564647c4bb4e > ProcessGdbRemoteTests`lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::GetQXferMemoryMapRegionInfo(this=0x000056464d53e580, > addr=16384, region=0x00007f2d1eb0a6c0) at > GDBRemoteCommunicationClient.cpp:1583* > * frame #14: 0x0000564647c4b95d > ProcessGdbRemoteTests`lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::GetMemoryRegionInfo(this=0x000056464d53e580, > addr=16384, region_info=0x00007ffd8b1a8870) at > GDBRemoteCommunicationClient.cpp:1558* > * frame #15: 0x000056464797ee25 > ProcessGdbRemoteTests`operator(__closure=0x000056464d5636a8) at > GDBRemoteCommunicationClientTest.cpp:339* > > It seems that the client is attempting extra communication which is not > modeled in the mock HandlePacket(), so it simply hangs in there. If that's > the case I'd expect this issue to be more widespread (unless my source tree > is in a broken state). > > This is the fist time I looked at this part of the code so it's possible I > missed something obvious though. > > > > On Fri, Apr 27, 2018 at 2:11 AM, Pavel Labath <lab...@google.com> wrote: > >> 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.GetMemoryReg >> ionInfoInvalidResponse >> >> >> > 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
