<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Step over misbehaves with multiple threads on Linux"
href="https://bugs.llvm.org/show_bug.cgi?id=45642">45642</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Step over misbehaves with multiple threads on Linux
</td>
</tr>
<tr>
<th>Product</th>
<td>lldb
</td>
</tr>
<tr>
<th>Version</th>
<td>10.0
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>All Bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>lldb-dev@lists.llvm.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>jarin@google.com
</td>
</tr>
<tr>
<th>CC</th>
<td>jdevlieghere@apple.com, llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>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</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>