[lldb-dev] LLDB tests getting stuck on GDBRemoteCommunicationClientTest.GetMemoryRegionInfo ?

[Pavel Labath via lldb-dev]

Right, I see what's going on now. Yes, you're right, the commit you mention
has added extra packets which are not handled in the mock. The reason this
is hanging for you is because you are using a debug build, which has a much
larger packet timeout (1000s i think). In the release build this passes,
because the second packet is optional and the function treats the lack of
response to the second packet as an error/not implemented. If you waited
for 15 minutes, I think you'd see the tests pass as well.

I'll have this fixed soon.
On Tue, 1 May 2018 at 21:26, Leonard Mosescu <mosescu at google.com> wrote:

> 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 <mosescu at 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 <labath at google.com> wrote:

>>> On Thu, 26 Apr 2018 at 22:58, Leonard Mosescu via lldb-dev <
>>> lldb-dev at 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.