Re: [lldb-dev] LLDB tests getting stuck on GDBRemoteCommunicationClientTest.GetMemoryRegionInfo ?
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 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 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 0x7fe4bdfbb6cd in pthread_join (threadid=140620333614848, thread_return=0x0) at pthread_join.c:90 >> ... >> #14 0x55b855bdf370 in std::future::get (this=0x7ffe4498aad0) at /usr/include/c++/7/future:796 >> #15 0x55b855b8c502 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: 0x564647c39a23 ProcessGdbRemoteTests`lldb_private::process_gdb_remote::GDBRemoteClientBase::SendPacketAndWaitForResponse(this=0x56464d53e580, payload=(Data = "qSupported:xmlRegisters=i386,arm,mips", Length = 37), response=0x7f2d1eb0a0e0, send_async=false) at GDBRemoteClientBase.cpp:176 >> frame #10: 0x564647c44e0a ProcessGdbRemoteTests`lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::GetRemoteQSupported(this=0x56464d53e580) at GDBRemoteCommunicationClient.cpp:370 >> frame #11: 0x564647c4427b ProcessGdbRemoteTests`lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::GetQXferMemoryMapReadSupported(this=0x56464d53e580) at GDBRemoteCommunicationClient.cpp:200 >> frame #12: 0x564647c4c661 ProcessGdbRemoteTests`lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::LoadQXferMemoryMap(this=0x56464d53e580) at GDBRemoteCommunicationClient.cpp:1609 >> frame #13: 0x564647c4bb4e ProcessGdbRemoteTests`lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::GetQXferMemoryMapRegionInfo(this=0x56464d53e580, addr=16384, region=0x7f2d1eb0a6c0) at GDBRemoteCommunicationClient.cpp:1583 >> frame #14: 0x564647c4b95d ProcessGdbRemoteTests`lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::GetMemoryRegionInfo(this=0x56464d53e580, addr=16384, region_info=0x7ffd8b1a8870) at GDBRemoteCommunicationClient.cpp:1558 >> frame #15: 0x56464797ee25 ProcessGdbRemoteTests`operator(__closure=0x56464d5636a8) 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 wrote: >>> On Thu, 26 Apr 2018 at 22:58, Leonard Mosescu via lldb-dev < >>> lldb-dev@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 GDBRemoteTestUtil
Re: [lldb-dev] LLDB tests getting stuck on GDBRemoteCommunicationClientTest.GetMemoryRegionInfo ?
Ok, r331374 ought to fix that. The situation was a bit more complicated then I thought, because the function was behaving differently if one builds lldb with xml support, so i've had to update the test to work correctly in both situations. On Wed, 2 May 2018 at 16:34, Pavel Labath wrote: > 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 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 > 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 0x7fe4bdfbb6cd in pthread_join (threadid=140620333614848, > thread_return=0x0) at pthread_join.c:90 > >> ... > >> #14 0x55b855bdf370 in std::future::get > (this=0x7ffe4498aad0) at /usr/include/c++/7/future:796 > >> #15 0x55b855b8c502 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: 0x564647c39a23 ProcessGdbRemoteTests`lldb_private::process_gdb_remote::GDBRemoteClientBase::SendPacketAndWaitForResponse(this=0x56464d53e580, > payload=(Data = "qSupported:xmlRegisters=i386,arm,mips", Length = 37), > response=0x7f2d1eb0a0e0, send_async=false) at > GDBRemoteClientBase.cpp:176 > >> frame #10: 0x564647c44e0a ProcessGdbRemoteTests`lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::GetRemoteQSupported(this=0x56464d53e580) > at GDBRemoteCommunicationClient.cpp:370 > >> frame #11: 0x564647c4427b ProcessGdbRemoteTests`lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::GetQXferMemoryMapReadSupported(this=0x56464d53e580) > at GDBRemoteCommunicationClient.cpp:200 > >> frame #12: 0x564647c4c661 ProcessGdbRemoteTests`lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::LoadQXferMemoryMap(this=0x56464d53e580) > at GDBRemoteCommunicationClient.cpp:1609 > >> frame #13: 0x564647c4bb4e ProcessGdbRemoteTests`lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::GetQXferMemoryMapRegionInfo(this=0x56464d53e580, > addr=16384, region=0x7f2d1eb0a6c0) at > GDBRemoteCommunicationClient.cpp:1583 > >> frame #14: 0x564647c4b95d ProcessGdbRemoteTests`lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::GetMemoryRegionInfo(this=0x56464d53e580, > addr=16384, region_info=0x7ffd8b1a8870) at > GDBRemoteCommunicationClient.cpp:1558 > >> frame #15: 0x56464797ee25 > ProcessGdbRemoteTests`operator(__closure=0x56464d5636a8) 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 wrote: > >>> On Thu, 26 Apr 2018 at 22:58, Leonard Mosescu via lldb-dev < > >>> lldb-dev@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,
Re: [lldb-dev] LLDB tests getting stuck on GDBRemoteCommunicationClientTest.GetMemoryRegionInfo ?
Great, thanks Pavel! On Wed, May 2, 2018 at 10:06 AM, Pavel Labath wrote: > Ok, r331374 ought to fix that. The situation was a bit more complicated > then I thought, because the function was behaving differently if one builds > lldb with xml support, so i've had to update the test to work correctly in > both situations. > On Wed, 2 May 2018 at 16:34, Pavel Labath wrote: > > > 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 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 > > 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 0x7fe4bdfbb6cd in pthread_join (threadid=140620333614848, > > thread_return=0x0) at pthread_join.c:90 > > >> ... > > >> #14 0x55b855bdf370 in std::future::get > > (this=0x7ffe4498aad0) at /usr/include/c++/7/future:796 > > >> #15 0x55b855b8c502 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: 0x564647c39a23 > > ProcessGdbRemoteTests`lldb_private::process_gdb_remote:: > GDBRemoteClientBase::SendPacketAndWaitForResponse(this=0x56464d53e580, > > payload=(Data = "qSupported:xmlRegisters=i386,arm,mips", Length = 37), > > response=0x7f2d1eb0a0e0, send_async=false) at > > GDBRemoteClientBase.cpp:176 > > >> frame #10: 0x564647c44e0a > > ProcessGdbRemoteTests`lldb_private::process_gdb_remote:: > GDBRemoteCommunicationClient::GetRemoteQSupported(this=0x56464d53e580) > > at GDBRemoteCommunicationClient.cpp:370 > > >> frame #11: 0x564647c4427b > > ProcessGdbRemoteTests`lldb_private::process_gdb_remote:: > GDBRemoteCommunicationClient::GetQXferMemoryMapReadSupported > (this=0x56464d53e580) > > at GDBRemoteCommunicationClient.cpp:200 > > >> frame #12: 0x564647c4c661 > > ProcessGdbRemoteTests`lldb_private::process_gdb_remote:: > GDBRemoteCommunicationClient::LoadQXferMemoryMap(this=0x56464d53e580) > > at GDBRemoteCommunicationClient.cpp:1609 > > >> frame #13: 0x564647c4bb4e > > ProcessGdbRemoteTests`lldb_private::process_gdb_remote:: > GDBRemoteCommunicationClient::GetQXferMemoryMapRegionInfo( > this=0x56464d53e580, > > addr=16384, region=0x7f2d1eb0a6c0) at > > GDBRemoteCommunicationClient.cpp:1583 > > >> frame #14: 0x564647c4b95d > > ProcessGdbRemoteTests`lldb_private::process_gdb_remote:: > GDBRemoteCommunicationClient::GetMemoryRegionInfo(this=0x56464d53e580, > > addr=16384, region_info=0x7ffd8b1a8870) at > > GDBRemoteCommunicationClient.cpp:1558 > > >> frame #15: 0x56464797ee25 > > ProcessGdbRemoteTests`operator(__closure=0x56464d5636a8) 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 > wrote: > > > >>> On Thu, 26 Apr 2018 at 22:58, Leonard Mosescu via lldb-dev < > > >>> lldb-dev@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: > > > > >>> > ProcessGd
[lldb-dev] [Bug 37317] New: ModuleList::FindGlobalVariables fails with append=false
https://bugs.llvm.org/show_bug.cgi?id=37317 Bug ID: 37317 Summary: ModuleList::FindGlobalVariables fails with append=false Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: t...@tromey.com CC: llvm-b...@lists.llvm.org In my Rust work I found that ModuleList::FindGlobalVariables will not work properly when passed append=false. The issue comes because SymbolFileDWARF::FindGlobalVariables does: // If we aren't appending the results to this list, then clear the list if (!append) variables.Clear(); So, if there are multiple modules, later ones will erase the results from earlier ones. A simple fix would be to change ModuleList::FindGlobalVariables to do something like: if (!append) variables.Clear(); ... (*pos)->FindGlobalVariables(name, nullptr, true, max_matches, variable_list); That is, always pass append=true to the callees. I would submit a patch for this but I don't know how to write a test case. So, I thought I'd file this instead. I'm also going to fix it in my tree. -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
