Asked the wait abort test for three windows, and failed a run that reached none

[fdesbiens]

threadx_thread_wait_abort_and_isr_test was given a wall clock budget in #644 so an unreachable race window could not hang a run. Four runs of the same tree since then show the budget being reached far more often than the first green run suggested, and a pass being reported every time it was.

The measurements

Twenty configuration-runs of the non-SMP copy. Seven ran out of budget:

configuration	windows reached	elapsed
trace_build	3 of 10	121 s
disable_notify_callbacks	3 of 10	121 s
default_build_coverage	4 of 10	121 s
stack_checking	7 of 10	121 s
trace_build	0 of 10	121 s
disable_notify_callbacks	7 of 10	121 s
stack_checking	3 of 10	121 s

Every one of those reported a pass, and the shortfall message reaches only the uploaded artifact — ctest runs with --output-on-failure, so a passing test's output is not in the job log at all. The suite has been losing most of this test's coverage in whole configurations, in three of them at once, and reporting green.

Ten windows are not reachable inside any sensible budget

The loop runs in two modes rather than one, with nothing in between across those twenty runs:

• fast — a window arrives in milliseconds; ten of them cost under a second
• slow — a window costs between 17 and 40 seconds

Ten windows in the slow mode is 400 seconds at the worst rate, and the unbounded runs measured before #644 reached 726. Raising the budget far enough to cover that would put five configurations within reach of the sixty minute step timeout added in #641 — trading a quiet loss of coverage for a loud timeout risk.

The change

Ask for what a run can reach. WAIT_ABORT_WINDOWS_WANTED goes from 10 to 3 in the non-SMP copy. Three windows cost 51 to 120 seconds in the slow mode and under a second in the fast one. The rationale committed with #644 applies directly: the value is in reaching the window at all, and the later hits repeat what the first ones establish.

Budget 120 → 180 seconds. Three windows at the worst rate measured is exactly the 120 it was, which would have truncated at two.

Report the count on every run, not only on a short one. A number that appears only on shortfall cannot be told apart from a number nobody recorded.

Reaching no window at all now fails. That case is different in kind from falling short: the check after the loop compares semaphore bookkeeping that a window has to have touched to mean anything, so a run that reached none compares a counter against the value it was initialised to and reports a pass having verified nothing. Such a run keeps trying to a 300 second ceiling and fails with ERROR #8 if it still has not reached the window. A resonance that holds for five minutes is worth a failure.

The SMP copy keeps its count of twenty. It reaches them in under half a second in all five of its configurations across all four runs, so the slow mode has never been observed there and that coverage is free. Both copies get the ceiling and the unconditional report, so the logic stays identical between them — the divergence in #648 was a reminder of what happens when it does not.

Verification

In CI, in the slow mode. The verification run happened to land in the slow mode, which is the case that matters, and every configuration reached full coverage inside the new budget:

ThreadX configuration	result	elapsed
trace_build	3 of 3	39.3 s
disable_notify_callbacks	3 of 3	38.2 s
default_build_coverage	3 of 3	38.0 s
stack_checking	3 of 3	27.3 s
stack_checking_rand_fill	3 of 3	10.0 s

All five SMP configurations reached 20 of 20 in 0 to 1 second. Every suite passed in full: ThreadX 96 of 96 and SMP 110 of 110 across five configurations each, FreeRTOS 3 of 3, with suite totals of 36 to 70 seconds per configuration.

The new failure path fires, and only when it should. With the handler's window made unreachable and the ceiling lowered to 5 seconds, the test stops after 6 seconds, prints the count it reached, and reports ERROR #8 with the harness recording a failure rather than a pass. With the count raised past what the budget allows, a run that reaches two windows still passes — so falling short and reaching nothing stay distinct.

Locally, all five configurations reach 3 of 3 in 5 to 14 seconds, and both suites pass 96 of 96 and 110 of 110 run one test at a time.

The TX_NOT_INTERRUPTABLE branch is compile-checked in both copies using the configurations' own compile commands. No configuration in either suite builds it, so it is not covered by a normal run; condition_count is expected to be zero there, which is why the new failure is compiled out of that path.

Known, and deliberately not addressed here

threadx_thread_delayed_suspension_test has the same shape of hole. Since #645 it skips its dependent check when its window is not reached, so a zero-window run there is also a pass that verified nothing. It has never fallen short in twenty configuration-runs — 4.06 seconds against a 120 second budget at worst — so there is no measured problem to fix, and it is left alone rather than changed on the strength of an argument by analogy.

One unrelated intermittent turned up while measuring. threadx_smp_random_resume_suspend_exclusion_pt_test failed with ERROR #7 on a first attempt in trace_build and passed on retry, on a sixteen core machine running the suite one test at a time. It did not recur in any CI run, including one with --repeat until-pass:1, so it is recorded here rather than diagnosed.