<div dir="ltr">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.<div><br></div><div>Patch is pending review.</div><div><br></div><div>Thanks for your explanations and ideas. It was very helpful.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 24, 2015 at 4:41 PM, Jim Ingham <span dir="ltr"><<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Jun 24, 2015, at 4:40 PM, Jim Ingham <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br>
><br>
> Just for giggles, try:<br>
><br>
> settings clear target.process.thread.step-avoid-regexp<br>
><br>
> 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.<br>
<br>
</span>Wrote too quickly. Should be:<br>
<br>
lldb by default doesn't stop when STEPPING would stop code that comes from std.<br>
<span class="HOEnZb"><font color="#888888"><br>
Jim<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
><br>
> Jim<br>
><br>
>> On Jun 24, 2015, at 4:36 PM, Adrian McCarthy <<a href="mailto:amccarth@google.com">amccarth@google.com</a>> wrote:<br>
>><br>
>> Thanks for the sanity check. I've been studying the step logging, but I'll keep at it.<br>
>><br>
>> On Wed, Jun 24, 2015 at 4:32 PM, Jim Ingham <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> Jim<br>
>><br>
>> 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...<br>
>><br>
>> Jim<br>
>><br>
>><br>
>>> On Jun 24, 2015, at 4:08 PM, Adrian McCarthy <<a href="mailto:amccarth@google.com">amccarth@google.com</a>> wrote:<br>
>>><br>
>>> 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:<br>
>>><br>
>>> #include <thread><br>
>>> #include <chrono><br>
>>><br>
>>> int main() {<br>
>>> for (int i = 0; i < 10; ++i) {<br>
>>> std::this_thread::sleep_for(std::chrono::milliseconds(10));<br>
>>> }<br>
>>> return 0;<br>
>>> }<br>
>>><br>
>>> If I set the breakpoint on the sleep_for call, it gets hit the first time.<br>
>>><br>
>>> (lldb) target create "a.exe"<br>
>>> Current executable set to 'a.exe' (i686).<br>
>>> (lldb) br set -l 6<br>
>>> Breakpoint 1: where = a.exe`main + 36 at hello.cpp:6, address = 0x00423044<br>
>>> (lldb) list<br>
>>> (lldb) process launch<br>
>>> Process 9892 launching<br>
>>> Process 9892 launched: 'D:\src\hello\a.exe' (i686)<br>
>>> (lldb) Process 9892 stopped<br>
>>> * thread #1: tid = 0x216c, 0x001c3044 a.exe`main + 36 at hello.cpp:6, stop reason = breakpoint 1.1<br>
>>> frame #0: 0x001c3044 a.exe`main + 36 at hello.cpp:6<br>
>>> 3<br>
>>> 4 int main() {<br>
>>> 5 for (int i = 0; i < 10; ++i) {<br>
>>> -> 6 std::this_thread::sleep_for(std::chrono::milliseconds(10));<br>
>>> 7 }<br>
>>> 8 return 0;<br>
>>> 9 }<br>
>>> frame variable<br>
>>> (int) i = 0<br>
>>><br>
>>> 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:<br>
>>><br>
>>> (lldb) continue<br>
>>> Process 9892 resuming<br>
>>> (lldb) Process 9892 exited with status = 0 (0x00000000)<br>
>>><br>
>>> 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.<br>
>>><br>
>>> I've been trying to fix TestCreateAfterAttach.py on Windows, but a very similar issue is blocking.<br>
>>><br>
>>> Is my expectation incorrect? Is this problem specific to Windows?<br>
>>><br>
>>> Thanks,<br>
>>> Adrian.<br>
>>><br>
>>> _______________________________________________<br>
>>> lldb-dev mailing list<br>
>>> <a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
>><br>
>><br>
><br>
<br>
</div></div></blockquote></div><br></div>