06c7835670
I did manage to turn a crash into a non-zero return code, but on the very first build it managed to time out. I thought I had the appetite to tweak timeouts but on second thought, I don't want yet another test to look out for. The test is not wrong, but on heavily loaded machines it's always going to be inherently unstable.
39 lines
1.4 KiB
Python
39 lines
1.4 KiB
Python
"""Test the lldb public C++ api when doing multiple debug sessions simultaneously."""
|
|
|
|
import os
|
|
import subprocess
|
|
|
|
import lldb
|
|
from lldbsuite.test.decorators import *
|
|
from lldbsuite.test.lldbtest import *
|
|
from lldbsuite.test import lldbutil
|
|
|
|
|
|
class TestMultipleSimultaneousDebuggers(TestBase):
|
|
NO_DEBUG_INFO_TESTCASE = True
|
|
|
|
# Times out on heavily loaded Linux buildbots, don't want to get into tweaking
|
|
# the timeout per bot. Does work when run alone. See:
|
|
# https://github.com/llvm/llvm-project/issues/101162
|
|
@skipIfLinux
|
|
@skipIfNoSBHeaders
|
|
@skipIfWindows
|
|
@skipIfHostIncompatibleWithTarget
|
|
def test_multiple_debuggers(self):
|
|
self.driver_exe = self.getBuildArtifact("multi-process-driver")
|
|
self.buildDriver(
|
|
"multi-process-driver.cpp",
|
|
self.driver_exe,
|
|
defines=[("LLDB_HOST_ARCH", lldbplatformutil.getArchitecture())],
|
|
)
|
|
self.addTearDownHook(lambda: os.remove(self.driver_exe))
|
|
|
|
self.inferior_exe = self.getBuildArtifact("testprog")
|
|
self.buildDriver("testprog.cpp", self.inferior_exe)
|
|
self.addTearDownHook(lambda: os.remove(self.inferior_exe))
|
|
|
|
# check_call will raise a CalledProcessError if the executable doesn't
|
|
# return exit code 0 to indicate success. We can let this exception go
|
|
# - the test harness will recognize it as a test failure.
|
|
subprocess.check_call([self.driver_exe, self.inferior_exe])
|