> 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
