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 <thread>
#include <chrono>
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.
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
