[lldb-dev] breakpoints inside loops

[Adrian McCarthy]

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 <jingham at 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 <amccarth at 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 at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150624/bbc32210/attachment.html>