This test fails on the assertion # At this point, the inferior process should have exited. self.assertTrue(self.inferior_process.GetState() == lldb.eStateExited, PROCESS_EXITED) output: runCmd: thread list output: Process 84775 stopped * thread #2: tid = 102403, 0x00000000004008a3 a.out`thread_func(input=0x0000000000000000) + 323 at main.cpp:43, stop reason = step out thread #3: tid = 101935, 0x0000000000400744 a.out`step_out_of_here() + 4 at main.cpp:33, stop reason = breakpoint 1.1 thread #1: tid = 103003, 0x000000080082a4dc libthr.so.3 at _umtx_op_err.S:37 Expecting sub string: * thread #2 Matched runCmd: thread backtrace all output: * thread #2: tid = 102403, 0x00000000004008a3 a.out`thread_func(input=0x0000000000000000) + 323 at main.cpp:43, stop reason = step out * frame #0: 0x00000000004008a3 a.out`thread_func(input=0x0000000000000000) + 323 at main.cpp:43 frame #1: 0x0000000800822d34 libthr.so.3`thread_start(curthread=0x0000000801807c00) + 260 at thr_create.c:284 thread #3: tid = 101935, 0x0000000000400744 a.out`step_out_of_here() + 4 at main.cpp:33, stop reason = breakpoint 1.1 frame #0: 0x0000000000400744 a.out`step_out_of_here() + 4 at main.cpp:33 frame #1: 0x00000000004008a3 a.out`thread_func(input=0x0000000000000000) + 323 at main.cpp:43 frame #2: 0x0000000800822d34 libthr.so.3`thread_start(curthread=0x0000000801807800) + 260 at thr_create.c:284 thread #1: tid = 103003, 0x000000080082a4dc libthr.so.3 at _umtx_op_err.S:37 frame #0: 0x000000080082a4dc libthr.so.3 at _umtx_op_err.S:37 Expecting sub string: main.cpp:43 Matched Expecting sub string: main.cpp:33 Matched runCmd: continue output: Process 84775 resuming Process 84775 stopped FAILURE Running the commands manually shows that the inferior stops again with stop reason = trace, rather then exiting. (lldb) thread step-out -m this-thread Process 84825 stopped * thread #2: tid = 103032, 0x00000000004008a3 a.out`thread_func(input=0x0000000000000000) + 323 at main.cpp:43, stop reason = step out frame #0: 0x00000000004008a3 a.out`thread_func(input=0x0000000000000000) + 323 at main.cpp:43 40 pseudo_barrier_wait(g_barrier); 41 42 // Do something -> 43 step_out_of_here(); // Expect to stop here after step-out (clang) 44 45 // Return 46 return NULL; // Expect to stop here after step-out (icc and gcc) thread #3: tid = 103013, 0x0000000000400744 a.out`step_out_of_here() + 4 at main.cpp:33, stop reason = breakpoint 1.1 frame #0: 0x0000000000400744 a.out`step_out_of_here() + 4 at main.cpp:33 30 volatile int g_test = 0; 31 32 void step_out_of_here() { -> 33 g_test += 5; // Set breakpoint here 34 } 35 36 void * (lldb) c Process 84825 resuming Process 84825 stopped * thread #2: tid = 103032, 0x00000000004008ad a.out`thread_func(input=0x0000000000000000) + 333 at main.cpp:46, stop reason = trace frame #0: 0x00000000004008ad a.out`thread_func(input=0x0000000000000000) + 333 at main.cpp:46 43 step_out_of_here(); // Expect to stop here after step-out (clang) 44 45 // Return -> 46 return NULL; // Expect to stop here after step-out (icc and gcc) 47 } 48 49 int main ()
Created attachment 11987 [details] LLDb stdout - demonstarting bug in libthr.so.3: pthread_kill()
Extremely sorry, The attachment 'LLDB stdout - pthread_kill() bug ' was attached to the wrong PR.
As of today $ bin/lldb-dotest -p TestThreadStepOut -f test_step_single_thread_dwarf reports XFAIL for this test; I have not confirmed that the issue is the same as reported in 2013.
Well, the test is broken at the moment, apparently due to API change: ERROR: test_step_single_thread_dwarf (TestThreadStepOut.ThreadStepOutTestCase) Test thread step out on one thread via command interpreter. ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1823, in test_method return attrvalue(self) File "/usr/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 105, in wrapper func(*args, **kwargs) File "/usr/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 105, in wrapper func(*args, **kwargs) File "/usr/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 105, in wrapper func(*args, **kwargs) File "/usr/home/mgorny/llvm-project/lldb/test/API/functionalities/thread/step_out/TestThreadStepOut.py", line 31, in test_step_single_thread self.step_out_test(self.step_out_single_thread_with_cmd) File "/usr/home/mgorny/llvm-project/lldb/test/API/functionalities/thread/step_out/TestThreadStepOut.py", line 148, in step_out_test bkpt_threads = lldbutil.continue_to_breakpoint(bkpt) TypeError: continue_to_breakpoint() missing 1 required positional argument: 'bkpt' Config=x86_64-/home/mgorny/llvm-project/_build/bin/clang However, if I fix it, all three cases fail with a new message: FAIL: test_step_single_thread_dwarf (TestThreadStepOut.ThreadStepOutTestCase) Test thread step out on one thread via command interpreter. ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1823, in test_method return attrvalue(self) File "/usr/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 105, in wrapper func(*args, **kwargs) File "/usr/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 105, in wrapper func(*args, **kwargs) File "/usr/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 105, in wrapper func(*args, **kwargs) File "/usr/home/mgorny/llvm-project/lldb/test/API/functionalities/thread/step_out/TestThreadStepOut.py", line 31, in test_step_single_thread self.step_out_test(self.step_out_single_thread_with_cmd) File "/usr/home/mgorny/llvm-project/lldb/test/API/functionalities/thread/step_out/TestThreadStepOut.py", line 150, in step_out_test self.assertEqual(len(bkpt_threads), 1, "Second thread stopped") AssertionError: 2 != 1 : Second thread stopped Config=x86_64-/home/mgorny/llvm-project/_build/bin/clang On Linux, it seems to suffer from some weird Makefile issue.