[lldb-dev] [Bug 45642] New: Step over misbehaves with multiple threads on Linux

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=45642

            Bug ID: 45642
           Summary: Step over misbehaves with multiple threads on Linux
           Product: lldb
           Version: 10.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: lldb-dev at lists.llvm.org
          Reporter: jarin at google.com
                CC: jdevlieghere at apple.com, llvm-bugs at lists.llvm.org

Stepping over a line can report a spurious SIGTRAP when the thread hits a real
(public) breakpoint while another thread hits the step-over plan's private
breakpoint.

A repro is shown below (it is not 100% deterministic, but seems to repro in
more than 50% of cases). We have two threads; with one thread, we step over a
function call and hits a public breakpoint there, the other thread hits a
private breakpoint that was placed by the first thread's step-over plan (more
precisely, by its step-out child plan). When the debugger stops, it selects
that thread that hit the private breakpoint and confusingly reports SIGTRAP. 

The repro console session:

$ cat u.cc
#include <thread>

void g() {
  printf(".");
}

void f() {
  while (true) {
    g();  // Break here, continue, then step over twice.
  }
}

int main() {
  std::thread t1(f);
  std::thread t2(f);

  t1.join();
  t2.join();
  return 0;
}

$ clang++ -O0 -g -pthread u.cc
$ lldb --version
lldb version 11.0.0
  clang revision cfd235e6fc7a2306644ee63bfea310d79084ef66
  llvm revision cfd235e6fc7a2306644ee63bfea310d79084ef66
$ lldb a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) b u.cc:9
Breakpoint 1: where = a.out`f() + 9 at u.cc:9:5, address = 0x00000000004011f9
(lldb) r
Process 229470 launched: 'a.out' (x86_64)
Process 229470 stopped
* thread #2, name = 'a.out', stop reason = breakpoint 1.1
    frame #0: 0x00000000004011f9 a.out`f() at u.cc:9:5
   6    
   7    void f() {
   8      while (true) {
-> 9        g();  // Break here, then step over.
   10     }
   11   }
   12   
(lldb) c
Process 229470 resuming
Process 229470 stopped
* thread #3, name = 'a.out', stop reason = breakpoint 1.1
    frame #0: 0x00000000004011f9 a.out`f() at u.cc:9:5
   6    
   7    void f() {
   8      while (true) {
-> 9        g();  // Break here, then step over.
   10     }
   11   }
   12   
(lldb) n
Process 229470 stopped
* thread #3, name = 'a.out', stop reason = step over
    frame #0: 0x00000000004011fe a.out`f() at u.cc:8:3
   5    }
   6    
   7    void f() {
-> 8      while (true) {
   9        g();  // Break here, then step over.
   10     }
   11   }
(lldb) n
Process 229470 stopped
* thread #2, name = 'a.out', stop reason = signal SIGTRAP
    frame #0: 0x00000000004011fe a.out`f() at u.cc:8:3
   5    }
   6    
   7    void f() {
-> 8      while (true) {
   9        g();  // Break here, then step over.
   10     }
   11   }
  thread #3, name = 'a.out', stop reason = breakpoint 1.1
    frame #0: 0x00000000004011f9 a.out`f() at u.cc:9:5
   6    
   7    void f() {
   8      while (true) {
-> 9        g();  // Break here, then step over.
   10     }
   11   }
   12


There is also a related problem where step-over seemingly steps into a
function. This happens when another thread hits a public breakpoint at the same
time as the step over plan single-steps.

$ lldb a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) b t.cc:9
Breakpoint 1: where = a.out`f() + 9 at t.cc:9:5, address = 0x0000000000401209
(lldb) r
Process 193890 launched: 'jarin/a.out' (x86_64)
Process 193890 stopped
* thread #2, name = 'a.out', stop reason = breakpoint 1.1
    frame #0: 0x0000000000401209 a.out`f() at t.cc:9:5
   6    
   7    void f() {
   8      while (true) {
-> 9        g();
   10     }
   11   }
   12   
(lldb) n
Process 193890 stopped
* thread #2, name = 'a.out', stop reason = step over
    frame #0: 0x000000000040120e a.out`f() at t.cc:8:3
   5    }
   6    
   7    void f() {
-> 8      while (true) {
   9        g();
   10     }
   11   }
  thread #3, name = 'a.out', stop reason = breakpoint 1.1
    frame #0: 0x0000000000401209 a.out`f() at t.cc:9:5
   6    
   7    void f() {
   8      while (true) {
-> 9        g();
   10     }
   11   }
   12   
(lldb) n
Process 193890 stopped
* thread #2, name = 'a.out', stop reason = breakpoint 1.1
    frame #0: 0x0000000000401209 a.out`f() at t.cc:9:5
   6    
   7    void f() {
   8      while (true) {
-> 9        g();
   10     }
   11   }
   12   
  thread #3, name = 'a.out', stop reason = breakpoint 1.1
    frame #0: 0x0000000000401209 a.out`f() at t.cc:9:5
   6    
   7    void f() {
   8      while (true) {
-> 9        g();
   10     }
   11   }
   12   
(lldb) 
Process 193890 stopped
* thread #2, name = 'a.out', stop reason = step over
    frame #0: 0x000000000040120e a.out`f() at t.cc:8:3
   5    }
   6    
   7    void f() {
-> 8      while (true) {
   9        g();
   10     }
   11   }
(lldb) n 
Process 193890 stopped
* thread #2, name = 'a.out', stop reason = breakpoint 1.1
    frame #0: 0x0000000000401209 a.out`f() at t.cc:9:5
   6    
   7    void f() {
   8      while (true) {
-> 9        g();
   10     }
   11   }
   12   
  thread #3, name = 'a.out', stop reason = signal SIGTRAP
    frame #0: 0x000000000040120e a.out`f() at t.cc:8:3
   5    }
   6    
   7    void f() {
-> 8      while (true) {
   9        g();
   10     }
   11   }
(lldb) n
Process 193890 stopped
* thread #2, name = 'a.out', stop reason = trace
    frame #0: 0x00000000004011d0 a.out`g() at t.cc:3
   1    #include <thread>
   2    
-> 3    void g() {
   4      printf(".");
   5    }
   6    
   7    void f() {
  thread #3, name = 'a.out', stop reason = breakpoint 1.1
    frame #0: 0x0000000000401209 a.out`f() at t.cc:9:5
   6    
   7    void f() {
   8      while (true) {
-> 9        g();
   10     }
   11   }
   12

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20200422/d1a9d5ef/attachment.html>