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

[Leonard Mosescu via lldb-dev]

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.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.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180501/9136892c/attachment-0001.html>