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 <jing...@apple.com> wrote:
>
> > On Jun 24, 2015, at 4:40 PM, Jim Ingham <jing...@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 <amcca...@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 <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
