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

[Jim Ingham via lldb-commits]

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