[lldb-dev] breakpoints inside loops

[Jim Ingham]

> 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
>> 
>> 
>