<div dir="ltr">PS. just a wild guess, could it be related to : <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">rL327970: Re-land: [lldb] Use vFlash commands when writing to target's flash memory… ?</span></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 1, 2018 at 1:24 PM, Leonard Mosescu <span dir="ltr"><<a href="mailto:mosescu@google.com" target="_blank">mosescu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks Pavel. It doesn't look like a timeout to me:<div><br></div><div>1. First, the other (main) thread is just waiting on the std::future::get() on the final EXPECT_TRUE(result.get()<wbr>.Success())</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div><i>#0 0x00007fe4bdfbb6cd in pthread_join (threadid=140620333614848, thread_return=0x0) at pthread_join.c:90</i></div></div></div><div><div><i>...</i></div></div><div><div><i>#14 0x000055b855bdf370 in std::future<lldb_private::<wbr>Status>::get (this=0x7ffe4498aad0) at /usr/include/c++/7/future:796</i></div></div><div><div><i>#15 0x000055b855b8c502 in GDBRemoteCommunicationClientTe<wbr>st_GetMemoryRegionInfo_Test::<wbr>TestBody (this=0x55b85bc195d0)</i></div></div><div><div><i> at /usr/local/google/home/<wbr>mosescu/extra/llvm/src/tools/<wbr>lldb/unittests/Process/gdb-<wbr>remote/<wbr>GDBRemoteCommunicationClientTe<wbr>st.cpp:</i>330</div></div></blockquote><div><div><br></div><div>2. The part that seems interesting to me is this part of the callstack I mentioned:</div><span class=""><div><div><br></div><div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><div><i><b> frame #9: 0x0000564647c39a23 ProcessGdbRemoteTests`lldb_pri<wbr>vate::process_gdb_remote::GDBR<wbr>emoteClientBase::SendPacketAnd<wbr>WaitForResponse(this=<wbr>0x000056464d53e580, payload=(Data = "qSupported:xmlRegisters=i386,<wbr>arm,mips", Length = 37), response=0x00007f2d1eb0a0e0, send_async=false) at GDBRemoteClientBase.cpp:176</b></i></div></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><div><i> frame #10: 0x0000564647c44e0a ProcessGdbRemoteTests`lldb_pri<wbr>vate::process_gdb_remote::GDBR<wbr>emoteCommunicationClient::GetR<wbr>emoteQSupported(this=0x0000564<wbr>64d53e580) at GDBRemoteCommunicationClient.c<wbr>pp:370</i></div></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><div><i><b> frame #11: 0x0000564647c4427b ProcessGdbRemoteTests`lldb_pri<wbr>vate::process_gdb_remote::GDBR<wbr>emoteCommunicationClient::GetQ<wbr>XferMemoryMapReadSupported(<wbr>this=0x000056464d53e580) at GDBRemoteCommunicationClient.c<wbr>pp:200</b></i></div></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><div><i> frame #12: 0x0000564647c4c661 ProcessGdbRemoteTests`lldb_pri<wbr>vate::process_gdb_remote::GDBR<wbr>emoteCommunicationClient::Load<wbr>QXferMemoryMap(this=0x00005646<wbr>4d53e580) at GDBRemoteCommunicationClient.c<wbr>pp:1609</i></div></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><div><i> frame #13: 0x0000564647c4bb4e ProcessGdbRemoteTests`lldb_pri<wbr>vate::process_gdb_remote::GDBR<wbr>emoteCommunicationClient::GetQ<wbr>XferMemoryMapRegionInfo(this=<wbr>0x000056464d53e580, addr=16384, region=0x00007f2d1eb0a6c0) at GDBRemoteCommunicationClient.c<wbr>pp:1583</i></div></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><div><i><b> frame #14: 0x0000564647c4b95d ProcessGdbRemoteTests`lldb_pri<wbr>vate::process_gdb_remote::GDBR<wbr>emoteCommunicationClient::GetM<wbr>emoryRegionInfo(this=0x0000564<wbr>64d53e580, addr=16384, region_info=0x00007ffd8b1a8870<wbr>) at GDBRemoteCommunicationClient.c<wbr>pp:1558</b></i></div></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><div><i> frame #15: 0x000056464797ee25 ProcessGdbRemoteTests`operator<wbr>(__closure=0x000056464d5636a8) at GDBRemoteCommunicationClientTe<wbr>st.cpp:339</i></div></div><br></div></div></span></div><div>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).</div><div><br></div><div>This is the fist time I looked at this part of the code so it's possible I missed something obvious though.</div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 27, 2018 at 2:11 AM, Pavel Labath <span dir="ltr"><<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Thu, 26 Apr 2018 at 22:58, Leonard Mosescu via lldb-dev <<br>
<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
<br>
> I just did a clean build (debug) on Linux, and I noticed that the LLDB<br>
tests seem to consistently get stuck:<br>
<br>
> -- Testing:<br>
1002 tests, 12 threads --<br>
<br>
> 99%<br>
[=============================<wbr>==============================<wbr>==============================<wbr>==============================<wbr>===================-]<br>
ETA: 00:00:01<br>
> lldb-Suite :: types/TestIntegerTypes.py<br>
<br>
<br>
> At this point there are a bunch of llvm-lit processes waiting and two<br>
suspicious LLDB unit tests:<br>
<br>
<br>
> ProcessGdbRemoteTests<br>
--gtest_filter=GDBRemoteCommun<wbr>icationClientTest.<wbr>GetMemoryRegionInfo<br>
> ProcessGdbRemoteTests<br>
--gtest_filter=GDBRemoteCommun<wbr>icationClientTest.GetMemoryReg<wbr>ionInfoInvalidResponse<br>
<br>
<br>
> I took a quick look and they both seem to blocked on communicating with<br>
the remote:<br>
<br>
> thread #2, name = 'ProcessGdbRemot', stop reason = signal SIGSTOP<br>
<br>
</span>These tests should have two threads communicating with each other. Can you<br>
check what the other thread is doing?<br>
<br>
My bet would be that fact that we are now running dotest tests concurrently<br>
with the unittests is putting more load on the system (particularly in<br>
debug builds), and the communication times out. You can try increasing the<br>
timeout in GDBRemoteTestUtils.cpp:GetPack<wbr>et to see if that helps.<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>