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 is doing something like process.GetThreadAtIndex(0) in our test suite is broken on Windows. This fixes a large number of these cases, although there are still a few more difficult ones remaining that I don't plan to address right now.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Yea that seems like a good idea. I can do that in a followup.
Jim, does this patch look ok to you?
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_threads_stopped_at_breakpoint as it is a more complete test. As noted in the individual comments, I don't think you are using get_threads_stopped_at_breakpoint right, since it returns an array of threads, not a single thread.
BTW, I'm not averse to the notion of an API to get the "main thread" but none of these tests should be changed to use it (or should have used it if it already existed.) After all, you wanted to know that you stopped on a thread at some breakpoint you set. The fact that that is the "main" thread is incidental and gating ALL these tests on having "the main thread" even be a sensible notion for your platform seems to make them fragile for no benefit.
packages/Python/lldbsuite/test/expression_command/test/TestExprs.py | ||
---|---|---|
133–134 ↗ | (On Diff #45046) | Is this one right? get_threads_stopped_at_breakpoint returns an array. You need to check that the return has only one element and then set thread to that element. Unless there's some Python magic that I'm missing... |
packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py | ||
40 ↗ | (On Diff #45046) | Is this one right? get_threads_stopped_at_breakpoint returns an array. You need to check that the return has only one element and then set thread to that element. Unless there's some Python magic that I'm missing... |
54–55 ↗ | (On Diff #45046) | Is this one right? get_threads_stopped_at_breakpoint returns an array. You need to check that the return has only one element and then set thread to that element. Unless there's some Python magic that I'm missing... |
packages/Python/lldbsuite/test/functionalities/conditional_break/TestConditionalBreak.py | ||
67–68 ↗ | (On Diff #45046) | Is this one right? get_threads_stopped_at_breakpoint returns an array. You need to check that the return has only one element and then set thread to that element. Unless there's some Python magic that I'm missing... |
Oh, yeah, I'm supposed to say "request changes" for the use of get_threads_stopped_at_breakpoint...
Fix incorrect usage of get_threads_stopped_at_breakpoint by adding a new function that returns the first thread stopped at a breakpoint.
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.
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 more than one did. I think it would be better if this API returned None for number of threads != 1, not just threads == 0. That way you'd get testing for that for free as well. And then in the cases where it was expected that more than one thread might hit the breakpoint, you should use get_threads_stopped_at_breakpoint.
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)
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.