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

[Leonard Mosescu via lldb-dev]

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