diff options
author | David Spickett <david.spickett@linaro.org> | 2025-06-13 09:31:57 +0100 |
---|---|---|
committer | GitHub <noreply@github.com> | 2025-06-13 09:31:57 +0100 |
commit | addd98f7a5b964a5a5860d65f327f3fc3b7e0a42 (patch) | |
tree | e8f3b132f4a4ff148b92f366ec1bd8be85695d0f /llvm/lib/ProfileData/Coverage/CoverageMapping.cpp | |
parent | 0cf333878d310bf9bbc8156cb7d8a0e271fb2c6f (diff) | |
download | llvm-addd98f7a5b964a5a5860d65f327f3fc3b7e0a42.zip llvm-addd98f7a5b964a5a5860d65f327f3fc3b7e0a42.tar.gz llvm-addd98f7a5b964a5a5860d65f327f3fc3b7e0a42.tar.bz2 |
[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.
Diffstat (limited to 'llvm/lib/ProfileData/Coverage/CoverageMapping.cpp')
0 files changed, 0 insertions, 0 deletions