[lldb-dev] breakpoints inside loops

[Adrian McCarthy]

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.

On Wed, Jun 24, 2015 at 4:41 PM, Jim Ingham <jingham at apple.com> wrote:

>
> > On Jun 24, 2015, at 4:40 PM, Jim Ingham <jingham at apple.com> wrote:
> >
> > 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
>
>
> >
> > Jim
> >
> >> On Jun 24, 2015, at 4:36 PM, Adrian McCarthy <amccarth at google.com>
> wrote:
> >>
> >> 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/20150701/df69aa17/attachment.html>