This is an archive of the discontinued LLVM Phabricator instance.

Don't assume that thread 0 is always the main thread
ClosedPublic

Authored by zturner on Jan 15 2016, 3:54 PM.

Details

Summary

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.

Diff Detail

Event Timeline

zturner updated this revision to Diff 45046.Jan 15 2016, 3:54 PM
zturner retitled this revision from to Don't assume that thread 0 is always the main thread.
zturner updated this object.
zturner added a reviewer: jingham.
zturner added a subscriber: lldb-commits.

A GetMainThread method in SBAPI might be a nice addition to GetThreadAtIndex.

Yea that seems like a good idea. I can do that in a followup.

Jim, does this patch look ok to you?

jingham edited edge metadata.Jan 19 2016, 1:46 PM

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

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

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

55–57

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

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

jingham requested changes to this revision.Jan 19 2016, 1:47 PM
jingham edited edge metadata.

Oh, yeah, I'm supposed to say "request changes" for the use of get_threads_stopped_at_breakpoint...

This revision now requires changes to proceed.Jan 19 2016, 1:47 PM
zturner updated this revision to Diff 45302.Jan 19 2016, 2:08 PM
zturner edited edge metadata.

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.

jingham requested changes to this revision.Jan 19 2016, 2:16 PM
jingham edited edge metadata.

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.

This revision now requires changes to proceed.Jan 19 2016, 2:16 PM

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.

This revision was automatically updated to reflect the committed changes.