<div dir="ltr">Great, thanks Pavel!</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 2, 2018 at 10:06 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">Ok, r331374 ought to fix that. The situation was a bit more complicated<br>
then I thought, because the function was behaving differently if one builds<br>
lldb with xml support, so i've had to update the test to work correctly in<br>
both situations.<br>
<div class="HOEnZb"><div class="h5">On Wed, 2 May 2018 at 16:34, Pavel Labath <<a href="mailto:labath@google.com">labath@google.com</a>> wrote:<br>
<br>
> Right, I see what's going on now. Yes, you're right, the commit you<br>
mention<br>
> has added extra packets which are not handled in the mock. The reason this<br>
> is hanging for you is because you are using a debug build, which has a<br>
much<br>
> larger packet timeout (1000s i think). In the release build this passes,<br>
> because the second packet is optional and the function treats the lack of<br>
> response to the second packet as an error/not implemented. If you waited<br>
> for 15 minutes, I think you'd see the tests pass as well.<br>
<br>
> I'll have this fixed soon.<br>
> On Tue, 1 May 2018 at 21:26, Leonard Mosescu <<a href="mailto:mosescu@google.com">mosescu@google.com</a>> wrote:<br>
<br>
> > PS. just a wild guess, could it be related to : rL327970: Re-land:<br>
[lldb]<br>
> Use vFlash commands when writing to target's flash memory… ?<br>
<br>
> > On Tue, May 1, 2018 at 1:24 PM, Leonard Mosescu <<a href="mailto:mosescu@google.com">mosescu@google.com</a>><br>
> wrote:<br>
<br>
> >> Thanks Pavel. It doesn't look like a timeout to me:<br>
<br>
> >> 1. First, the other (main) thread is just waiting on the<br>
> std::future::get() on the final EXPECT_TRUE(result.get().<wbr>Success())<br>
<br>
> >> #0 0x00007fe4bdfbb6cd in pthread_join (threadid=140620333614848,<br>
> thread_return=0x0) at pthread_join.c:90<br>
> >> ...<br>
> >> #14 0x000055b855bdf370 in std::future<lldb_private::<wbr>Status>::get<br>
> (this=0x7ffe4498aad0) at /usr/include/c++/7/future:796<br>
> >> #15 0x000055b855b8c502 in<br>
> GDBRemoteCommunicationClientTe<wbr>st_GetMemoryRegionInfo_Test::<wbr>TestBody<br>
> (this=0x55b85bc195d0)<br>
> >> at<br>
<br>
/usr/local/google/home/<wbr>mosescu/extra/llvm/src/tools/<wbr>lldb/unittests/Process/gdb-<wbr>remote/<wbr>GDBRemoteCommunicationClientTe<wbr>st.cpp:330<br>
<br>
<br>
> >> 2. The part that seems interesting to me is this part of the callstack<br>
I<br>
> mentioned:<br>
<br>
> >> frame #9: 0x0000564647c39a23<br>
<br>
ProcessGdbRemoteTests`lldb_<wbr>private::process_gdb_remote::<wbr>GDBRemoteClientBase::<wbr>SendPacketAndWaitForResponse(<wbr>this=0x000056464d53e580,<br>
> payload=(Data = "qSupported:xmlRegisters=i386,<wbr>arm,mips", Length = 37),<br>
> response=0x00007f2d1eb0a0e0, send_async=false) at<br>
> GDBRemoteClientBase.cpp:176<br>
> >> frame #10: 0x0000564647c44e0a<br>
<br>
ProcessGdbRemoteTests`lldb_<wbr>private::process_gdb_remote::<wbr>GDBRemoteCommunicationClient::<wbr>GetRemoteQSupported(this=<wbr>0x000056464d53e580)<br>
> at GDBRemoteCommunicationClient.<wbr>cpp:370<br>
> >> frame #11: 0x0000564647c4427b<br>
<br>
ProcessGdbRemoteTests`lldb_<wbr>private::process_gdb_remote::<wbr>GDBRemoteCommunicationClient::<wbr>GetQXferMemoryMapReadSupported<wbr>(this=0x000056464d53e580)<br>
> at GDBRemoteCommunicationClient.<wbr>cpp:200<br>
> >> frame #12: 0x0000564647c4c661<br>
<br>
ProcessGdbRemoteTests`lldb_<wbr>private::process_gdb_remote::<wbr>GDBRemoteCommunicationClient::<wbr>LoadQXferMemoryMap(this=<wbr>0x000056464d53e580)<br>
> at GDBRemoteCommunicationClient.<wbr>cpp:1609<br>
> >> frame #13: 0x0000564647c4bb4e<br>
<br>
ProcessGdbRemoteTests`lldb_<wbr>private::process_gdb_remote::<wbr>GDBRemoteCommunicationClient::<wbr>GetQXferMemoryMapRegionInfo(<wbr>this=0x000056464d53e580,<br>
> addr=16384, region=0x00007f2d1eb0a6c0) at<br>
> GDBRemoteCommunicationClient.<wbr>cpp:1583<br>
> >> frame #14: 0x0000564647c4b95d<br>
<br>
ProcessGdbRemoteTests`lldb_<wbr>private::process_gdb_remote::<wbr>GDBRemoteCommunicationClient::<wbr>GetMemoryRegionInfo(this=<wbr>0x000056464d53e580,<br>
> addr=16384, region_info=<wbr>0x00007ffd8b1a8870) at<br>
> GDBRemoteCommunicationClient.<wbr>cpp:1558<br>
> >> frame #15: 0x000056464797ee25<br>
> ProcessGdbRemoteTests`<wbr>operator(__closure=<wbr>0x000056464d5636a8) at<br>
> GDBRemoteCommunicationClientTe<wbr>st.cpp:339<br>
<br>
> >> It seems that the client is attempting extra communication which is not<br>
> modeled in the mock HandlePacket(), so it simply hangs in there. If that's<br>
> the case I'd expect this issue to be more widespread (unless my source<br>
tree<br>
> is in a broken state).<br>
<br>
> >> This is the fist time I looked at this part of the code so it's<br>
possible<br>
> I missed something obvious though.<br>
<br>
<br>
<br>
> >> On Fri, Apr 27, 2018 at 2:11 AM, Pavel Labath <<a href="mailto:labath@google.com">labath@google.com</a>><br>
wrote:<br>
<br>
> >>> On Thu, 26 Apr 2018 at 22:58, Leonard Mosescu via lldb-dev <<br>
> >>> <a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br>
<br>
> >>> > I just did a clean build (debug) on Linux, and I noticed that the<br>
LLDB<br>
> >>> tests seem to consistently get stuck:<br>
<br>
> >>> > --<br>
> Testing:<br>
> >>> 1002 tests, 12 threads --<br>
<br>
> >>> > 99%<br>
<br>
<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<br>
two<br>
> >>> suspicious LLDB unit tests:<br>
<br>
<br>
> >>> > ProcessGdbRemoteTests<br>
> >>> --gtest_filter=<wbr>GDBRemoteCommunicationClientTe<wbr>st.GetMemoryRegionInfo<br>
> >>> > ProcessGdbRemoteTests<br>
<br>
<br>
--gtest_filter=<wbr>GDBRemoteCommunicationClientTe<wbr>st.<wbr>GetMemoryRegionInfoInvalidResp<wbr>onse<br>
<br>
<br>
> >>> > I took a quick look and they both seem to blocked on communicating<br>
> with<br>
> >>> the remote:<br>
<br>
> >>> > thread #2, name = 'ProcessGdbRemot', stop reason = signal SIGSTOP<br>
<br>
> >>> These tests should have two threads communicating with each other. Can<br>
> you<br>
> >>> check what the other thread is doing?<br>
<br>
> >>> My bet would be that fact that we are now running dotest tests<br>
> 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<br>
> the<br>
> >>> timeout in GDBRemoteTestUtils.cpp:<wbr>GetPacket to see if that helps.<br>
</div></div></blockquote></div><br></div>