DavidSpickett wrote:
If this PR is approved, and `TestGdbRemoteFork.py` gives you trouble, splitting
it sounds good.
I suspect folks will be on board with splitting these extremely long tests, but
I will hold off approving for a few days in case that's not the case.
https://github.com/llvm/ll
dmpots wrote:
> How many others are close to the limit that you've found, just this one?
I was only seeing the one timeout in the runs so I had not thought to measure.
It's a good idea though. Based on the timings it looks like maybe
`TestGdbRemoteFork.py` is worth splitting as well? That one
@@ -5,9 +5,9 @@
lldb-server tests run where the lldb-server exe is
available.
-This class will be broken into smaller test case classes by
-gdb remote packet functional areas. For now it contains
-the initial set of tests implemented.
+The tests are split between the LldbGdbS
https://github.com/dmpots updated
https://github.com/llvm/llvm-project/pull/129614
>From bb034b3b8c43dae13d7f596c20863b47ce88e4d4 Mon Sep 17 00:00:00 2001
From: David Peixotto
Date: Mon, 3 Mar 2025 15:39:20 -0800
Subject: [PATCH 1/2] Split test to avoid timeout
This test is running right up to
@@ -5,9 +5,9 @@
lldb-server tests run where the lldb-server exe is
available.
-This class will be broken into smaller test case classes by
-gdb remote packet functional areas. For now it contains
-the initial set of tests implemented.
+The tests are split between the LldbGdbS
DavidSpickett wrote:
Even for a debug build, timeouts aren't a good experience. The sleeps as you
say are a minority of the time, and I would rather not disturb them anyway.
So I agree with splitting this.
How many others are close to the limit that you've found, just this one?
https://github
