Thanks for the sanity check. I've been studying the step logging, but I'll
keep at it.
On Wed, Jun 24, 2015 at 4:32 PM, Jim Ingham <jing...@apple.com> wrote:
> 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
>
>
> > On Jun 24, 2015, at 4:08 PM, Adrian McCarthy <amcca...@google.com>
> wrote:
> >
> > 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
>
>
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
