[all-commits] [llvm/llvm-project] addd98: [lldb][test] Don't call SBDebugger::Terminate if T...

[David Spickett via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: addd98f7a5b964a5a5860d65f327f3fc3b7e0a42
      https://github.com/llvm/llvm-project/commit/addd98f7a5b964a5a5860d65f327f3fc3b7e0a42
  Author: David Spickett <david.spickett at linaro.org>
  Date:   2025-06-13 (Fri, 13 Jun 2025)

  Changed paths:
    M lldb/test/API/api/multiple-debuggers/TestMultipleDebuggers.py
    M lldb/test/API/api/multiple-debuggers/multi-process-driver.cpp

  Log Message:
  -----------
  [lldb][test] Don't call SBDebugger::Terminate if TestMultipleDebuggers times out (#143732)

Fixes #101162

This test did this:
* SBDebugger::Initialize
* Spawn a bunch of threads that do:
  * SBDebugger::Create
  * some work
  * SBDebugger::Destroy
* Wait on those threads to finish then call SBDebugger::Terminate and
exit, or -
* Reach a time limit before all the threads finish, call
SBDebugger::Terminate and exit.

The problem was that in the timeout case, calling SBDebugger::Terminate
destroys data being used by threads that are still running. I expect
this test was expecting said threads to be so broken they were probably
stuck, but when the machine is just heavily loaded, one of them might
read that data before the whole program exits.

This means what should have been a timeout becomes a crash. Sometimes.
Which explains why we saw both timeouts and various signals on the
AArch64 Linux bot. It depends on the timings.

So I'm changing it not to call SBDebugger::Terminate in the timeout
case. We will have to tweak the timeout value based on what happens on
the buildbot, but we will know it's machine load not an lldb bug.

Also use _exit instead of exit, to skip more cleanup that might cause a
crash.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications