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 <jing...@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 >> <revi...@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 >> >> >> > _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
