breakpoints inside loops

I’m finding that when I set a breakpoint inside a small loop, the breakpoint triggers only the first time. For example, given this code:

#include

#include

int main() {

for (int i = 0; i < 10; ++i) {

std::this_thread::sleep_for(std::chrono::milliseconds(10));

}

return 0;

}

If I set the breakpoint on the sleep_for call, it gets hit the first time.

(lldb) target create “a.exe”

Current executable set to ‘a.exe’ (i686).

(lldb) br set -l 6

Breakpoint 1: where = a.exe`main + 36 at hello.cpp:6, address = 0x00423044

(lldb) list

(lldb) process launch

Process 9892 launching

Process 9892 launched: ‘D:\src\hello\a.exe’ (i686)

(lldb) Process 9892 stopped

  • thread #1: tid = 0x216c, 0x001c3044 a.exe`main + 36 at hello.cpp:6, stop reason = breakpoint 1.1

frame #0: 0x001c3044 a.exe`main + 36 at hello.cpp:6

3

4 int main() {

5 for (int i = 0; i < 10; ++i) {

→ 6 std::this_thread::sleep_for(std::chrono::milliseconds(10));

7 }

8 return 0;

9 }

frame variable

(int) i = 0

So far, so good. But now, if I try to continue, I’d expect the breakpoint to be hit again, for the i = 1 iteration. Instead:

(lldb) continue

Process 9892 resuming

(lldb) Process 9892 exited with status = 0 (0x00000000)

If I turn on various levels of locking, I see that the breakpoint hits, but the ThreadList::ShouldStop test fails, so the process resumes again and again until the loop terminates.

I’ve been trying to fix TestCreateAfterAttach.py on Windows, but a very similar issue is blocking.

Is my expectation incorrect? Is this problem specific to Windows?

Thanks,
Adrian.

I don't see this behavior with the same source on OS X - compiled with a pretty recent clang. It stops every time around the loop as you would expect.

The useful log for these cases is the "step" log. If you post the step log, and the disassembly of the function we are stepping through ("disassemble -f" when you stop in the function) I'll take a look. The step log can get kind of long, so it will be easier to read if you run to the first breakpoint hit, then turn on the step log, then continue, so the log will have only the incorrect continues.

Jim

P.S. I'll be on vacation Thurs-Mon, so if I don't get to it by the end of the day it may take till Tuesday next...

Jim

Thanks for the sanity check. I’ve been studying the step logging, but I’ll keep at it.

Just for giggles, try:

settings clear target.process.thread.step-avoid-regexp

lldb by default doesn't stop on breakpoint hits in code that comes from std. Maybe there's some inlined goo from std that we think we've stopped in, and that is why we are auto-continuing.

Jim

Just for giggles, try:

settings clear target.process.thread.step-avoid-regexp

lldb by default doesn't stop on breakpoint hits in code that comes from std. Maybe there's some inlined goo from std that we think we've stopped in, and that is why we are auto-continuing.

Wrote too quickly. Should be:

lldb by default doesn't stop when STEPPING would stop code that comes from std.

Jim

To close the loop here … the problem had to do with parts of TargetThreadWindows mixing up m_resume_state and m_temporary_resume_state, which had all sorts of consequences. This was uncovered by my earlier state-change fix from a couple weeks ago.

Patch is pending review.

Thanks for your explanations and ideas. It was very helpful.