[Lldb-commits] [PATCH] D33426: Introduce new command: thread backtrace unique

[Pavel Labath via lldb-commits]

Woops, my bad. I was hoping that "resume" was to "StepInstruction",
which does have an immediate action, but i did not check what it
actually does.

In this case, we could probably just use "StepOut" for the test case,
as it should have the same effect - advance the thread until it
reaches the next breakpoint.

On 31 May 2017 at 19:22, Jim Ingham <jingham at apple.com> wrote:
> SBThread::Resume instructs lldb to set the resume state on a thread to "eStateRunning", meaning that means the next time you continue the process, that thread will get a chance to run.  It has no effect on the StopReason for the thread (it doesn't even start it running except maybe in the not well supported "thread-centric" debugging mode.)
>
> In the normal case, nothing is going to happen till the process is resumed (with SBProcess::Continue).  At that point, the thread you just allowed to run might or might not actually get scheduled to run.  And if it does actually run, it might or might not have stopped for an interesting reason by the time the process stopped.  So getting eStopReasonNone in this case is not at all unexpected.  If NONE of the threads in the program had an interesting stop reason, that would be weird, and worth looking at.  But that you might have to wait around for a while for any particular thread to stop for some reason is not unexpected.
>
> Jim
>
>
>
>> On May 31, 2017, at 3:44 AM, Pavel Labath via Phabricator <reviews at reviews.llvm.org> wrote:
>>
>> labath added a comment.
>>
>> In https://reviews.llvm.org/D33426#766525, @bgianfo wrote:
>>
>>> Address Pavel and Greg's feedback on Diff 100365.
>>>
>>> Pavel: I took your suggestions to make the test case more readable,
>>> I really appreciate the guidance. I did have to tweak some of the
>>> functionality to make the test case pass reliably, as there were
>>> still some races possible. I also saw that SBThread.Resume() seems
>>> to occasionally result in a StopReason of eStopReasonNon. So I worked
>>> around that by only including threads int expected output that the Resume
>>> resulted in making it to our breakpoint. I have verified the test is
>>> consistently passes by executing it on repeat 100 times,
>>
>>
>> Thanks. The fact that we are not able to rely on the operation of Resume in this case sounds like a bug. Obviously we can't condition the acceptance of this patch by fixing that issue, but we should at least track it. Can you create a bug on bugs.llvm.org, and reference it in your workaround. BTW, what's the platform you are testing this on?
>>
>>
>> https://reviews.llvm.org/D33426
>>
>>
>>
>