This is an archive of the discontinued LLVM Phabricator instance.

[lldb/test] Remove sleeps from some lldb-server tests
ClosedPublic

Authored by labath on Feb 7 2022, 11:12 AM.

Details

Summary

Instead of using sleeps, have the inferior notify us (via a signal) that
the requested number of threads have been created.

This allows us to get rid of some fairly dodgy test utility code --
wait_for_thread_count seemed like it was waiting for the threads to
appear, but it never actually let the inferior run, so it only succeeded
if the threads were already started when the function was called. Since
the function was called after a fairly small delay (1s, usually), this
is probably the reason why the tests were failing on some bots.

Diff Detail

Event Timeline

labath requested review of this revision.Feb 7 2022, 11:12 AM
labath created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptFeb 7 2022, 11:12 AM
labath added a subscriber: aprantl.Feb 7 2022, 11:12 AM

I'm pretty sure I've seen this sort of failure before but can't remember if it was locally or on one of many bots. (which probably means all of them!) This seems like a good improvement.

lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
787

I don't think this is an issue but what would cause you to have > the number of threads?

Are there automatically created threads sometimes that we don't explicitly ask for.

lldb/test/API/tools/lldb-server/TestGdbRemoteThreadsInStopReply.py
22

If there's a very slim chance this text is "" you could assertTrue and catch both situations.

33–34

Afaict parse_key_val_dict will never return None. At worst an empty dictionary.

labath planned changes to this revision.Feb 8 2022, 2:35 AM
labath marked an inline comment as done.

Speaking of windows, I just realized that this method will (obviously) not work there. I should have occurred to me there was a reason I didn't do this earlier. Let me try a different synchronization method instead.

lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
787

Windows std::threads maintain a thread pool of spun-up threads, presumably to speed up their creation. It is somewhat annoying because, for some of these lower-level tests, we would really want to know the exact number of threads and their properties. One day, I'm going to create some some thread creation wrappers to avoid this...

lldb/test/API/tools/lldb-server/TestGdbRemoteThreadsInStopReply.py
22

technically, "" might be correct, if we decide to return a bare Txx packet for some reason.

33–34

Yeah, this code is being overly defensive.

labath updated this revision to Diff 406761.Feb 8 2022, 3:59 AM
labath marked 2 inline comments as done.

Use a trap opcode instead of a signal. This has two main drawbacks:

  • needs some architecture-specific code (gcc does not have __builtin_debugtrap)
  • if we ever need to resume from this state, we will need to add special handling to make progress on systems where the trap opcode does not increment the PC

I still think it beats sleeps, though.

DavidSpickett accepted this revision.Feb 8 2022, 5:43 AM

LGTM

lldb/test/API/tools/lldb-server/main.cpp
144

I thought this might need to be different for Windows on Arm64 but no, it's the same instruction https://docs.microsoft.com/en-us/cpp/intrinsics/debugbreak?redirectedfrom=MSDN&view=msvc-170.

This revision is now accepted and ready to land.Feb 8 2022, 5:43 AM
This revision was automatically updated to reflect the committed changes.

This looks amazing! Thanks, Pavel.