[lldb-dev] Crash in "intern-state" thread after removing breakpoints and continue
Hello,
I'm facing the following 6.0.0-rc1 crash on Linux/X86:
#0 0x70e027b6 in std::__uniq_ptr_impl >::_M_ptr (this=0x28)
at /usr/include/c++/7/bits/unique_ptr.h:147
#1 0x70e01cbe in std::unique_ptr >::get (this=0x28) at
/usr/include/c++/7/bits/unique_ptr.h:337
#2 0x70e00860 in
lldb_private::BreakpointOptions::GetThreadSpecNoCreate (this=0x0)
at
/home/dantipov/llvm/6.0.0/source/tools/lldb/source/Breakpoint/BreakpointOptions.cpp:524
#3 0x70df6474 in lldb_private::BreakpointLocation::ValidForThisThread
(this=0x61ad90, thread=0x7fffd40018f0)
at
/home/dantipov/llvm/6.0.0/source/tools/lldb/source/Breakpoint/BreakpointLocation.cpp:387
#4 0x70df8c2b in
lldb_private::BreakpointLocationCollection::ValidForThisThread (this=0x55e020,
thread=0x7fffd40018f0)
at
/home/dantipov/llvm/6.0.0/source/tools/lldb/source/Breakpoint/BreakpointLocationCollection.cpp:152
#5 0x70e10dd8 in lldb_private::BreakpointSite::ValidForThisThread
(this=0x55dfd0, thread=0x7fffd40018f0)
at
/home/dantipov/llvm/6.0.0/source/tools/lldb/source/Breakpoint/BreakpointSite.cpp:146
#6 0x714d602c in
lldb_private::process_gdb_remote::ProcessGDBRemote::SetThreadStopInfo
(this=0x5f1a40, tid=27530, expedited_register_map=..., signo=5 '\005',
thread_name=..., reason=..., description=..., exc_type=0, exc_data=...,
thread_dispatch_qaddr=18446744073709551615, queue_vars_valid=false,
associated_with_dispatch_queue=lldb_private::eLazyBoolCalculate,
dispatch_queue_t=18446744073709551615, queue_name=...,
queue_kind=lldb::eQueueKindUnknown, queue_serial=0)
at
/home/dantipov/llvm/6.0.0/source/tools/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:1880
#7 0x714da439 in
lldb_private::process_gdb_remote::ProcessGDBRemote::SetThreadStopInfo
(this=0x5f1a40, stop_packet=...)
at
/home/dantipov/llvm/6.0.0/source/tools/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:2371
#8 0x714da598 in
lldb_private::process_gdb_remote::ProcessGDBRemote::RefreshStateAfterStop
(this=0x5f1a40)
at
/home/dantipov/llvm/6.0.0/source/tools/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:2407
#9 0x7110378c in lldb_private::Process::ShouldBroadcastEvent
(this=0x5f1a40, event_ptr=0x7fffdc014a00)
at
/home/dantipov/llvm/6.0.0/source/tools/lldb/source/Target/Process.cpp:3658
#10 0x7110411d in lldb_private::Process::HandlePrivateEvent
(this=0x5f1a40, event_sp=...) at
/home/dantipov/llvm/6.0.0/source/tools/lldb/source/Target/Process.cpp:3907
#11 0x71104959 in lldb_private::Process::RunPrivateStateThread
(this=0x5f1a40, is_secondary_thread=false)
at
/home/dantipov/llvm/6.0.0/source/tools/lldb/source/Target/Process.cpp:4106
#12 0x711044b2 in lldb_private::Process::PrivateStateThread
(arg=0x614210) at
/home/dantipov/llvm/6.0.0/source/tools/lldb/source/Target/Process.cpp:3999
#13 0x70f7a6e7 in
lldb_private::HostNativeThreadBase::ThreadCreateTrampoline (arg=0x616250)
at
/home/dantipov/llvm/6.0.0/source/tools/lldb/source/Host/common/HostNativeThreadBase.cpp:66
#14 0x77bbf36d in start_thread () from /lib64/libpthread.so.0
#15 0x7fffef3d6b4f in clone () from /lib64/libc.so.6
Test program (bug.cc) and recipe to reproduce (bug.txt) attached.
7.0.0 SVN trunk looks also affected, but stable 5.0.1 isn't.
I've also requested an account at https://bugs.llvm.org, and will
create bug report as soon as my registration will be approved.
Dmitry
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
/*
* Compile with g++ -pthread -std=c++11 -O0 -g3 -o bug bug.cc
*/
#include
#include
#include
#include
#include
#include
int depth;
void
bp1 (int t, int level, int n)
{
auto r = std::rand () % (t + level + n);
std::this_thread::sleep_for (std::chrono::milliseconds (r));
}
void
bp2 (int t, int level, int n)
{
auto r = std::rand () % (t + level + n);
std::this_thread::sleep_for (std::chrono::milliseconds (r));
}
void
sleeper (int t, int level, int n)
{
int loop = 0;
if (++level < depth)
sleeper (t, level, n);
else
while (true)
{
if (++loop % 2)
bp1 (t, level, n);
else
bp2 (t, level, n);
}
}
int
main (int argc, char *argv[])
{
auto max = argc > 1 ? std::atoi (argv[1]) : 2;
depth = argc > 2 ? std::atoi (argv[2]) : 8;
std::vector T;
for (auto i = 0; i < max; i++)
{
auto t = new std::thread (sleeper, i, 0, 1000);
pthread_setname_np (t->native_handle (),
(std::string ("worker ")
[lldb-dev] [Bug 36251] New: Crash in "intern-state" thread after removing breakpoints and continue
https://bugs.llvm.org/show_bug.cgi?id=36251 Bug ID: 36251 Summary: Crash in "intern-state" thread after removing breakpoints and continue Product: lldb Version: 6.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: danti...@nvidia.com CC: llvm-b...@lists.llvm.org Created attachment 19816 --> https://bugs.llvm.org/attachment.cgi?id=19816&action=edit Test program to debug under LLDB Crash after removing breakpoints and continue: #0 0x70e027b6 in std::__uniq_ptr_impl >::_M_ptr (this=0x28) at /usr/include/c++/7/bits/unique_ptr.h:147 #1 0x70e01cbe in std::unique_ptr >::get (this=0x28) at /usr/include/c++/7/bits/unique_ptr.h:337 #2 0x70e00860 in lldb_private::BreakpointOptions::GetThreadSpecNoCreate (this=0x0) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Breakpoint/BreakpointOptions.cpp:524 #3 0x70df6474 in lldb_private::BreakpointLocation::ValidForThisThread (this=0x61ad90, thread=0x7fffd40018f0) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Breakpoint/BreakpointLocation.cpp:387 #4 0x70df8c2b in lldb_private::BreakpointLocationCollection::ValidForThisThread (this=0x55e020, thread=0x7fffd40018f0) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Breakpoint/BreakpointLocationCollection.cpp:152 #5 0x70e10dd8 in lldb_private::BreakpointSite::ValidForThisThread (this=0x55dfd0, thread=0x7fffd40018f0) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Breakpoint/BreakpointSite.cpp:146 #6 0x714d602c in lldb_private::process_gdb_remote::ProcessGDBRemote::SetThreadStopInfo (this=0x5f1a40, tid=27530, expedited_register_map=..., signo=5 '\005', thread_name=..., reason=..., description=..., exc_type=0, exc_data=..., thread_dispatch_qaddr=18446744073709551615, queue_vars_valid=false, associated_with_dispatch_queue=lldb_private::eLazyBoolCalculate, dispatch_queue_t=18446744073709551615, queue_name=..., queue_kind=lldb::eQueueKindUnknown, queue_serial=0) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:1880 #7 0x714da439 in lldb_private::process_gdb_remote::ProcessGDBRemote::SetThreadStopInfo (this=0x5f1a40, stop_packet=...) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:2371 #8 0x714da598 in lldb_private::process_gdb_remote::ProcessGDBRemote::RefreshStateAfterStop (this=0x5f1a40) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:2407 #9 0x7110378c in lldb_private::Process::ShouldBroadcastEvent (this=0x5f1a40, event_ptr=0x7fffdc014a00) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Target/Process.cpp:3658 #10 0x7110411d in lldb_private::Process::HandlePrivateEvent (this=0x5f1a40, event_sp=...) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Target/Process.cpp:3907 #11 0x71104959 in lldb_private::Process::RunPrivateStateThread (this=0x5f1a40, is_secondary_thread=false) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Target/Process.cpp:4106 #12 0x711044b2 in lldb_private::Process::PrivateStateThread (arg=0x614210) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Target/Process.cpp:3999 #13 0x70f7a6e7 in lldb_private::HostNativeThreadBase::ThreadCreateTrampoline (arg=0x616250) at /home/dantipov/llvm/6.0.0/source/tools/lldb/source/Host/common/HostNativeThreadBase.cpp:66 #14 0x77bbf36d in start_thread () from /lib64/libpthread.so.0 #15 0x7fffef3d6b4f in clone () from /lib64/libc.so.6 Steps to reproduce and full backtrace: $ gdb -q /home/dantipov/.local/llvm-6.0.0/bin/lldb Reading symbols from /home/dantipov/.local/llvm-6.0.0/bin/lldb...done. (gdb) r Starting program: /home/dantipov/.local/llvm-6.0.0/bin/lldb [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7fffede7e700 (LWP 28281)] (lldb) version lldb version 6.0.0 (http://llvm.org/svn/llvm-project/lldb/tags/RELEASE_600/rc1 revision 324341) clang revision 324341 llvm revision 324341 (lldb) at 27528 [New Thread 0x7fffed67d700 (LWP 28619)] [New Thread 0x7fffece7c700 (LWP 28620)] [New Thread 0x7fffe7fff700 (LWP 28624)] Process 27528 stopped * thread #1, name = 'bug', stop reason = signal SIGSTOP frame #0: 0x7fc50e8f989d libpthread.so.0`pthread_join + 189 libpthread.so.0`pthread_join: -> 0x7fc50e8f989d <+189>: movslq 0x2d0(%rbx), %rdx 0x7fc50e8f98a4 <+196>: testl %edx, %edx 0x7fc50e8f98a6 <+198>: jne0x7fc50e8f9890; <+176> 0x7fc50e8f98a8 <+200>: movl %r13d, %edi thread #2, name = 'worker 0', stop reason = signal SIGSTOP frame #0: 0
Re: [lldb-dev] [RFC] Testsuite in lldb & possible future directions
On 6 February 2018 at 04:11, Davide Italiano via lldb-dev wrote: > Hi, > in the last couple of months a lot of people put a lot of attentions > and energy into lldb and we're starting to see the first results. I > decided to sit down and write this e-mail to state where we are and > what are some possible future directions for the projects, in terms of > better quality/higher testability. > > Current state: > > 1) We got the testsuite on MacOS to build with zero unexpected > successes and zero failures (modulo one change I'm going to push > tomorrow). This is a collaborative effort and it's very important > because it allows us to push for unexpected successes as failures on > the bots, allowing us to discover issues quicker. Other platform I > think are improving their state as well, mainly thanks to the work of > Pavel and Jan. I don't mean to belittle this statement, as I think the situation has definitely improved a lot lately, but I feel I have to point out that's I've never been able to get a clean test suite run on a mac (not even the "0 failures" kind of clean). I'm not sure what are these caused by, but I guess that's because the tests are still very much dependent on the environment. So, I have to ask: what kind of environment are you running those tests in? My machine is not a completely off-the-shelf mac, as it has some google-specific customizations. I don't really know what this encompasses, but I would be surprised if these impact the result of the test suite. If I had to bet, my money would be on your machines having some apple-specific stuff which is not available in regular macs. I tried an experiment today. I configured with: cmake ../../llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON -GNinja. First problem I ran into was that I couldn't run check-lldb, as the clang I have just built was unable to compile any of the test binaries due to missing headers (this could be a manifestation of the SDKROOT issue we ran into a couple of weeks ago). So, I tried running with the system compiler and I got this output: FAIL: test_c_global_variables_dwarf (lang/c/global_variables/TestGlobalVariables.py) FAIL: test_c_global_variables_gmodules (lang/c/global_variables/TestGlobalVariables.py) FAIL: test_dsym (functionalities/ubsan/basic/TestUbsanBasic.py) FAIL: test_dwarf (functionalities/ubsan/basic/TestUbsanBasic.py) FAIL: test_gmodules (functionalities/ubsan/basic/TestUbsanBasic.py) FAIL: test_with_python_api_dsym (lang/cpp/class_static/TestStaticVariables.py) FAIL: test_with_python_api_dwarf (lang/cpp/class_static/TestStaticVariables.py) FAIL: test_with_python_api_gmodules (lang/cpp/class_static/TestStaticVariables.py) ERROR: test_debug_info_for_apple_types_dsym (macosx/debug-info/apple_types/TestAppleTypesIsProduced.py) ERROR: test_debug_info_for_apple_types_dwarf (macosx/debug-info/apple_types/TestAppleTypesIsProduced.py) ERROR: test_debug_info_for_apple_types_gmodules (macosx/debug-info/apple_types/TestAppleTypesIsProduced.py) UNEXPECTED SUCCESS: test_lldbmi_output_grammar (tools/lldb-mi/syntax/TestMiSyntax.py) UNEXPECTED SUCCESS: test_process_interrupt_dsym (functionalities/thread/state/TestThreadStates.py) UNEXPECTED SUCCESS: test_process_interrupt_gmodules (functionalities/thread/state/TestThreadStates.py) So, I guess my question is: are you guys looking into making sure that others are also able to reproduce the 0-fail+0-xpass state? I would love to run the mac test suite locally, as I tend to touch a lot of stuff that impacts all targets, but as it stands now, I have very little confidence that the test I am running reflect in any way the results you will get when you run the test on your end. I am ready to supply any test logs or information you need if you want to try to tackle this. > 3) In the short term I plan to remove support for unmaintained > languages (Java/Go/Swift). This allows us to bring them back again (or I hope you meant OCaml instead of Swift. :P ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Testsuite in lldb & possible future directions
On Tue, Feb 6, 2018 at 7:09 AM, Pavel Labath wrote: > On 6 February 2018 at 04:11, Davide Italiano via lldb-dev > wrote: >> Hi, >> in the last couple of months a lot of people put a lot of attentions >> and energy into lldb and we're starting to see the first results. I >> decided to sit down and write this e-mail to state where we are and >> what are some possible future directions for the projects, in terms of >> better quality/higher testability. >> >> Current state: >> >> 1) We got the testsuite on MacOS to build with zero unexpected >> successes and zero failures (modulo one change I'm going to push >> tomorrow). This is a collaborative effort and it's very important >> because it allows us to push for unexpected successes as failures on >> the bots, allowing us to discover issues quicker. Other platform I >> think are improving their state as well, mainly thanks to the work of >> Pavel and Jan. > > I don't mean to belittle this statement, as I think the situation has > definitely improved a lot lately, but I feel I have to point out > that's I've never been able to get a clean test suite run on a mac > (not even the "0 failures" kind of clean). I'm not sure what are these > caused by, but I guess that's because the tests are still very much > dependent on the environment. So, I have to ask: what kind of > environment are you running those tests in? > > My machine is not a completely off-the-shelf mac, as it has some > google-specific customizations. I don't really know what this > encompasses, but I would be surprised if these impact the result of > the test suite. If I had to bet, my money would be on your machines > having some apple-specific stuff which is not available in regular > macs. > > I tried an experiment today. I configured with: cmake ../../llvm > -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON -GNinja. First > problem I ran into was that I couldn't run check-lldb, as the clang I > have just built was unable to compile any of the test binaries due to > missing headers (this could be a manifestation of the SDKROOT issue we > ran into a couple of weeks ago). So, I tried running with the system > compiler and I got this output: > > FAIL: test_c_global_variables_dwarf > (lang/c/global_variables/TestGlobalVariables.py) > FAIL: test_c_global_variables_gmodules > (lang/c/global_variables/TestGlobalVariables.py) > FAIL: test_dsym (functionalities/ubsan/basic/TestUbsanBasic.py) > FAIL: test_dwarf (functionalities/ubsan/basic/TestUbsanBasic.py) > FAIL: test_gmodules (functionalities/ubsan/basic/TestUbsanBasic.py) > FAIL: test_with_python_api_dsym (lang/cpp/class_static/TestStaticVariables.py) > FAIL: test_with_python_api_dwarf > (lang/cpp/class_static/TestStaticVariables.py) > FAIL: test_with_python_api_gmodules > (lang/cpp/class_static/TestStaticVariables.py) > ERROR: test_debug_info_for_apple_types_dsym > (macosx/debug-info/apple_types/TestAppleTypesIsProduced.py) > ERROR: test_debug_info_for_apple_types_dwarf > (macosx/debug-info/apple_types/TestAppleTypesIsProduced.py) > ERROR: test_debug_info_for_apple_types_gmodules > (macosx/debug-info/apple_types/TestAppleTypesIsProduced.py) > UNEXPECTED SUCCESS: test_lldbmi_output_grammar > (tools/lldb-mi/syntax/TestMiSyntax.py) > UNEXPECTED SUCCESS: test_process_interrupt_dsym > (functionalities/thread/state/TestThreadStates.py) > UNEXPECTED SUCCESS: test_process_interrupt_gmodules > (functionalities/thread/state/TestThreadStates.py) > > So, I guess my question is: are you guys looking into making sure that > others are also able to reproduce the 0-fail+0-xpass state? I would > love to run the mac test suite locally, as I tend to touch a lot of > stuff that impacts all targets, but as it stands now, I have very > little confidence that the test I am running reflect in any way the > results you will get when you run the test on your end. > > I am ready to supply any test logs or information you need if you want > to try to tackle this. > Yes, I'm definitely interested in making the testusuite working/reliable on any configuration. I was afraid there were a lot of latent issues, that's why I sent this mail in the first place. It's also the reason why I started thinking about `lldb-test` as a driver for testing, because I found out the testsuite being a little inconsistent/brittle depending on the environment it's run on (which, FWIW, doesn't happen when you run lit/FileCheck or even the unit tests in lldb). I'm not currently claiming switching to a different method would improve the situation, but it's worth a shot. >> 3) In the short term I plan to remove support for unmaintained >> languages (Java/Go/Swift). This allows us to bring them back again (or > I hope you meant OCaml instead of Swift. :P Oh, yes, sigh. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Testsuite in lldb & possible future directions
On Tue, Feb 6, 2018 at 7:09 AM, Pavel Labath wrote: > On 6 February 2018 at 04:11, Davide Italiano via lldb-dev > wrote: >> Hi, >> in the last couple of months a lot of people put a lot of attentions >> and energy into lldb and we're starting to see the first results. I >> decided to sit down and write this e-mail to state where we are and >> what are some possible future directions for the projects, in terms of >> better quality/higher testability. >> >> Current state: >> >> 1) We got the testsuite on MacOS to build with zero unexpected >> successes and zero failures (modulo one change I'm going to push >> tomorrow). This is a collaborative effort and it's very important >> because it allows us to push for unexpected successes as failures on >> the bots, allowing us to discover issues quicker. Other platform I >> think are improving their state as well, mainly thanks to the work of >> Pavel and Jan. > > I don't mean to belittle this statement, as I think the situation has > definitely improved a lot lately, but I feel I have to point out > that's I've never been able to get a clean test suite run on a mac > (not even the "0 failures" kind of clean). I'm not sure what are these > caused by, but I guess that's because the tests are still very much > dependent on the environment. So, I have to ask: what kind of > environment are you running those tests in? > > My machine is not a completely off-the-shelf mac, as it has some > google-specific customizations. I don't really know what this > encompasses, but I would be surprised if these impact the result of > the test suite. If I had to bet, my money would be on your machines > having some apple-specific stuff which is not available in regular > macs. > > I tried an experiment today. I configured with: cmake ../../llvm > -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON -GNinja. First > problem I ran into was that I couldn't run check-lldb, as the clang I > have just built was unable to compile any of the test binaries due to > missing headers (this could be a manifestation of the SDKROOT issue we > ran into a couple of weeks ago). So, I tried running with the system > compiler and I got this output: > > FAIL: test_c_global_variables_dwarf > (lang/c/global_variables/TestGlobalVariables.py) > FAIL: test_c_global_variables_gmodules > (lang/c/global_variables/TestGlobalVariables.py) > FAIL: test_dsym (functionalities/ubsan/basic/TestUbsanBasic.py) > FAIL: test_dwarf (functionalities/ubsan/basic/TestUbsanBasic.py) > FAIL: test_gmodules (functionalities/ubsan/basic/TestUbsanBasic.py) > FAIL: test_with_python_api_dsym (lang/cpp/class_static/TestStaticVariables.py) > FAIL: test_with_python_api_dwarf > (lang/cpp/class_static/TestStaticVariables.py) > FAIL: test_with_python_api_gmodules > (lang/cpp/class_static/TestStaticVariables.py) > ERROR: test_debug_info_for_apple_types_dsym > (macosx/debug-info/apple_types/TestAppleTypesIsProduced.py) > ERROR: test_debug_info_for_apple_types_dwarf > (macosx/debug-info/apple_types/TestAppleTypesIsProduced.py) > ERROR: test_debug_info_for_apple_types_gmodules > (macosx/debug-info/apple_types/TestAppleTypesIsProduced.py) > UNEXPECTED SUCCESS: test_lldbmi_output_grammar > (tools/lldb-mi/syntax/TestMiSyntax.py) > UNEXPECTED SUCCESS: test_process_interrupt_dsym > (functionalities/thread/state/TestThreadStates.py) > UNEXPECTED SUCCESS: test_process_interrupt_gmodules > (functionalities/thread/state/TestThreadStates.py) > FWIW, I strongly believe we should all agree on a configuration to run tests and standardize on that. It's unfortunate that we have two build systems, but there are plans to move away from manually generating xcodebuild, as many agree it's a terrible maintenance burden. So, FWIW, I'll share my conf (I'm on high Sierra): git clone https://github.com/monorepo symlink clang -> tools symlink lldb -> tools symlink libcxx -> projects (this particular one has caused lots of trouble for me in the past, and I realized it's undocumented :() cmake -GNinja -DCMAKE_BUILD_TYPE=Release ../llvm ninja check-lldb This *should* work just fine for every developer (and we should error out if all the dependencies are not in place). If it doesn't, well, it's a bug. Can you please try with this and report all the bugs that you find? I'll work with you to fix them, as I'm particularly interested in getting the lldb experience for users flawlessly out-the-box (at least on the platforms I work on :) -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Testsuite in lldb & possible future directions
On 6 February 2018 at 15:41, Davide Italiano wrote: > On Tue, Feb 6, 2018 at 7:09 AM, Pavel Labath wrote: >> On 6 February 2018 at 04:11, Davide Italiano via lldb-dev >> >> So, I guess my question is: are you guys looking into making sure that >> others are also able to reproduce the 0-fail+0-xpass state? I would >> love to run the mac test suite locally, as I tend to touch a lot of >> stuff that impacts all targets, but as it stands now, I have very >> little confidence that the test I am running reflect in any way the >> results you will get when you run the test on your end. >> >> I am ready to supply any test logs or information you need if you want >> to try to tackle this. >> > > Yes, I'm definitely interested in making the testusuite > working/reliable on any configuration. > I was afraid there were a lot of latent issues, that's why I sent this > mail in the first place. > It's also the reason why I started thinking about `lldb-test` as a > driver for testing, because I found out the testsuite being a little > inconsistent/brittle depending on the environment it's run on (which, > FWIW, doesn't happen when you run lit/FileCheck or even the unit tests > in lldb). I'm not currently claiming switching to a different method > would improve the situation, but it's worth a shot. > Despite Zachary's claims, I do not believe this is caused by the test driver (dotest). It's definitely not beautiful, but I haven't seen an issue that would be caused by this in a long time. The issue is that the tests are doing too much -- even the simplest involves compiling a fully working executable, which pulls in a lot of stuff from the environment (runtime libraries, dynamic linker, ...) that we have no control of. And of course it makes it impossible to test the debugging functionality of any other platform than what you currently have in front of you. In this sense, the current setup makes an excellent integration test suite -- if you run the tests and they pass, you can be fairly confident that the debugging on your system is setup correctly. However, it makes a very bad regression test suite, as the tests will be checking something different on each machine. So I believe we need more lightweight tests, and lldb-test can provide us with that. The main question for me (and that's something I don't really have an answer to) is how to make writing tests like that easy. E.g. for these "foreign" language plugins, the only way to make a self-contained regression test would be to check-in some dwarf which mimics what the compiler in question would produce. But doing that is extremely tedious as we don't have any tooling for that. Since debug info is very central to what we do, having something like that would go a long way towards improving the testing situation, and it would be useful for C/C++ as well, as we generally need to make sure that we work with a wide range of compiler versions, not just accept what ToT clang happens to produce. PS: I saw your second email as well. I'm going to try out what you propose, most likely tomorrow. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Testsuite in lldb & possible future directions
On Tue, Feb 6, 2018 at 8:18 AM, Pavel Labath wrote: > On 6 February 2018 at 15:41, Davide Italiano wrote: >> On Tue, Feb 6, 2018 at 7:09 AM, Pavel Labath wrote: >>> On 6 February 2018 at 04:11, Davide Italiano via lldb-dev >>> >>> So, I guess my question is: are you guys looking into making sure that >>> others are also able to reproduce the 0-fail+0-xpass state? I would >>> love to run the mac test suite locally, as I tend to touch a lot of >>> stuff that impacts all targets, but as it stands now, I have very >>> little confidence that the test I am running reflect in any way the >>> results you will get when you run the test on your end. >>> >>> I am ready to supply any test logs or information you need if you want >>> to try to tackle this. >>> >> >> Yes, I'm definitely interested in making the testusuite >> working/reliable on any configuration. >> I was afraid there were a lot of latent issues, that's why I sent this >> mail in the first place. >> It's also the reason why I started thinking about `lldb-test` as a >> driver for testing, because I found out the testsuite being a little >> inconsistent/brittle depending on the environment it's run on (which, >> FWIW, doesn't happen when you run lit/FileCheck or even the unit tests >> in lldb). I'm not currently claiming switching to a different method >> would improve the situation, but it's worth a shot. >> > > Despite Zachary's claims, I do not believe this is caused by the test > driver (dotest). It's definitely not beautiful, but I haven't seen an > issue that would be caused by this in a long time. The issue is that > the tests are doing too much -- even the simplest involves compiling a > fully working executable, which pulls in a lot of stuff from the > environment (runtime libraries, dynamic linker, ...) that we have no > control of. And of course it makes it impossible to test the debugging > functionality of any other platform than what you currently have in > front of you. > > In this sense, the current setup makes an excellent integration test > suite -- if you run the tests and they pass, you can be fairly > confident that the debugging on your system is setup correctly. > However, it makes a very bad regression test suite, as the tests will > be checking something different on each machine. > Yes, I didn't complain about "dotest" in general, but, as you say, the fact that it pull in lots of stuffs we don't really have control on. Also, most of the times I actually found out we've been sloppy watching bots for a while, or XFAILING tests instead of fixing them and that resulted in issues piling up). This is a more general problem not necessarily tied to `dotest` as a driver. > So I believe we need more lightweight tests, and lldb-test can provide > us with that. The main question for me (and that's something I don't +1. > really have an answer to) is how to make writing tests like that easy. > E.g. for these "foreign" language plugins, the only way to make a > self-contained regression test would be to check-in some dwarf which > mimics what the compiler in question would produce. But doing that is > extremely tedious as we don't have any tooling for that. Since debug > info is very central to what we do, having something like that would > go a long way towards improving the testing situation, and it would be > useful for C/C++ as well, as we generally need to make sure that we > work with a wide range of compiler versions, not just accept what ToT > clang happens to produce. > I think the plan here (and I'd love to spend some time on this once we have stability, which seems we're slowly getting) is that of enhancing `yaml2*` to do the work for us. I do agree is a major undertaken but even spending a month on it will go a long way IMHO. I will try to come up with a plan after discussing with folks in my team (I'd really love to get also inputs from DWARF people in llvm, e.g. Eric or David Blake). > > PS: I saw your second email as well. I'm going to try out what you > propose, most likely tomorrow. Thanks! -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Testsuite in lldb & possible future directions
On Tue, Feb 6, 2018 at 8:19 AM Pavel Labath via lldb-dev < lldb-dev@lists.llvm.org> wrote: > On 6 February 2018 at 15:41, Davide Italiano > wrote: > > On Tue, Feb 6, 2018 at 7:09 AM, Pavel Labath wrote: > >> On 6 February 2018 at 04:11, Davide Italiano via lldb-dev > >> > >> So, I guess my question is: are you guys looking into making sure that > >> others are also able to reproduce the 0-fail+0-xpass state? I would > >> love to run the mac test suite locally, as I tend to touch a lot of > >> stuff that impacts all targets, but as it stands now, I have very > >> little confidence that the test I am running reflect in any way the > >> results you will get when you run the test on your end. > >> > >> I am ready to supply any test logs or information you need if you want > >> to try to tackle this. > >> > > > > Yes, I'm definitely interested in making the testusuite > > working/reliable on any configuration. > > I was afraid there were a lot of latent issues, that's why I sent this > > mail in the first place. > > It's also the reason why I started thinking about `lldb-test` as a > > driver for testing, because I found out the testsuite being a little > > inconsistent/brittle depending on the environment it's run on (which, > > FWIW, doesn't happen when you run lit/FileCheck or even the unit tests > > in lldb). I'm not currently claiming switching to a different method > > would improve the situation, but it's worth a shot. > > > > Despite Zachary's claims, I do not believe this is caused by the test > driver (dotest). It's definitely not beautiful, but I haven't seen an > issue that would be caused by this in a long time. The issue is that > the tests are doing too much -- even the simplest involves compiling a > fully working executable, which pulls in a lot of stuff from the > environment (runtime libraries, dynamic linker, ...) that we have no > control of. And of course it makes it impossible to test the debugging > functionality of any other platform than what you currently have in > front of you. > I'm not claiming that it's definitely caused by dotest and that moving away from dotest is going to fix all the problems. Rather, I'm claiming that dotest has an unknown amount of flakiness (which may be 0, but may be large), and the alternative has a known amount of flakiness (which is very close to, if not equal to 0). So we should do it because, among other benefits, it replaces an unknown with a known that is at least as good, if not better. > > In this sense, the current setup makes an excellent integration test > suite -- if you run the tests and they pass, you can be fairly > confident that the debugging on your system is setup correctly. > However, it makes a very bad regression test suite, as the tests will > be checking something different on each machine. > > So I believe we need more lightweight tests, and lldb-test can provide > us with that. The main question for me (and that's something I don't > really have an answer to) is how to make writing tests like that easy. > E.g. for these "foreign" language plugins, the only way to make a > self-contained regression test would be to check-in some dwarf which > mimics what the compiler in question would produce. But doing that is > extremely tedious as we don't have any tooling for that. Most of these other language plugins are being removed anyway. Which language plugins are going to still remain that aren't some flavor of c/c++? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Testsuite in lldb & possible future directions
On Mon, Feb 5, 2018 at 8:12 PM Davide Italiano via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > > Conclusions: > The reliability of the suite (and the health of the codebase) is very > important to us. If you have issues, let us know. > In general, I'm looking for any kind of feedback, feel free to speak! > > I think that the path forward is to massively expand test coverage in all areas. We need roughly 20x - 30x the amount of tests that we currently have. 25,000 ~ 30,000 tests that run equally well on all platforms is a good target to shoot for. The goal of tests is, obviously, to increase test coverage by increasing the amount of code that is tested. Another way to increase test coverage is to reduce the amount of code that isn't tested. If you can delete an untested branch then even if you don't add a test, you've increased test coverage. To that end, we should be looking to assert more liberally and end the dubious practice of defensive programming. On the subject of lldb-test. I think the existing test suite serves its purpose as an integration test suite well, and I would even say that it has a reasonable amount of test coverage from what you could expect of an integration test suite. But what we need is a regression test suite. I don't think we should spend a significant amount of time adding new tests to the integration test suite. It's coverage is already decent. I think almost all new tests going forward should be very lightweight, targeted, regression tests that do not depend on the host platform at all. lldb-test is the perfect vehicle for this kind of test. It's still early and doesn't do much, so we will need to continually add more functionality to lldb-test as well to realize this goal, but I think we can rapidly expand test coverage going this route. Finally, I think we should get buildbots running sanitized builds of LLDB under the test suite. For LLDB specifically I think TSan and UBSan would add the most value, but long term I think we should get all sanitizers enabled. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 36258] New: Include comprehensive list of all LLDB settings
https://bugs.llvm.org/show_bug.cgi?id=36258 Bug ID: 36258 Summary: Include comprehensive list of all LLDB settings Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: michael.ei...@gmail.com CC: llvm-b...@lists.llvm.org It would be great to see a full list of the settings for LLDB. Or, if it already exists, to make it easier to find. -- 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
[lldb-dev] FYI: LLDB DWARF tests on Windows are broken
It looks like tests of DWARF-specific functionality on Windows are failing because we're actually generating CodeView in a PDB rather than DWARF. For example, TestSignedTypes.py fails for reasons completely unrelated to whether the types are signed or not. Apparently DWARF and CodeView consider the bounds of the live range for the variables to be slightly different. When using CodeView info, there's a `thread step-over` command that takes you just outside the scope block, so the subsequent `frame variable` command fails to produce the expected output. The makefile creates compile steps with `-g` and link steps with `-fuse-lld`, so you'd expect DWARF, but, due to recent changes in clang and lld, this will actually produce CodeView/PDB when building for Windows. I'll look into a fix tomorrow. I'm told it might involve not only tweaking the makefile flags for these tests, but also ensuring that the clang driver passes the right flags to lld. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
