This revision was automatically updated to reflect the committed changes.
Closed by commit rL258432: Remove assumptions that thread 0 is always the main
thread. (authored by zturner).
Changed prior to commit:
http://reviews.llvm.org/D16247?vs=45302&id=45587#toc
Repository:
rL LLVM
http://re
jingham added a comment.
That would be fine too. Just seems like this is asking to have a miswritten
test that accidentally stops at two hits of the breakpoint but you didn't
notice because MOST of the time, the right thread was first, which would lead
to an odd flakey test.
http://reviews.l
zturner added a comment.
Maybe I can give it an argument like `require_exactly_one_thread` which
defaults to True. That way at least you can still use the same function in the
case where you just want the first thread (which is how `get_stopped_thread`
works)
http://reviews.llvm.org/D16247
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.
That looks good. get_one_thread_stopped_at_breakpoint is convenient, but I'd
rather not sweep under the rug cases where you expected only one thread to hit
your breakpoint but mor
zturner added a comment.
Fixed that issue. The other issue you pointed out about using
`get_stopped_thread` sometimes is because in those tests breakpoints were
created using `runCmd` so we don't have an `SBBreakpoint` handy like we do in
the other cases.
http://reviews.llvm.org/D16247
__
zturner updated this revision to Diff 45302.
zturner added a comment.
Fix incorrect usage of `get_threads_stopped_at_breakpoint` by adding a new
function that returns the first thread stopped at a breakpoint.
http://reviews.llvm.org/D16247
Files:
packages/Python/lldbsuite/test/expression_com
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.
Oh, yeah, I'm supposed to say "request changes" for the use of
get_threads_stopped_at_breakpoint...
http://reviews.llvm.org/D16247
_
jingham added a comment.
Yes, that is a cleaner way to do this.
In about half the cases you use get_threads_stopped_at_breakpoint and half
get_stopped_thread. It looks like you were just mirroring what the test did,
so that's fine, but if I know the breakpoint I'm expecting, I prefer
get_thre
zturner added a comment.
Yea that seems like a good idea. I can do that in a followup.
Jim, does this patch look ok to you?
http://reviews.llvm.org/D16247
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mail
amccarth added a subscriber: amccarth.
amccarth added a comment.
A GetMainThread method in SBAPI might be a nice addition to GetThreadAtIndex.
http://reviews.llvm.org/D16247
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm
zturner created this revision.
zturner added a reviewer: jingham.
zturner added a subscriber: lldb-commits.
Even in a single-threaded app, Windows will often create background threads on
startup and these threads can appear in any order with respect to the actual
main thread. So everywhere that
11 matches
Mail list logo
