Covered the thread stack check's fault arms from the test side

2026-09-15T16:44:23Z

TX_THREAD_STACK_CHECK sits on ten sites across the scheduler and scores seven conditions at each of them. Ordinary use only ever takes the clean arm of five: the stack pointer never goes below the lowest recorded, neither fence word is overwritten, the lowest recorded pointer stays inside the stack, the word under it is still fill, and the control block is always a thread. The ten sites sat between eight and eleven of fourteen for that reason, 47 outcomes in all. The new test gives a thread a fault, drives a site, and takes the fault out again. Five faults, each written into the thread's own control block or into the fence words around its stack: the lowest recorded stack pointer put above the thread's stack pointer, the fence above the stack overwritten, the lowest recorded pointer dropped below the stack, the word under it made used, and the fence below the stack overwritten. A sixth pass clears the thread identifier, which is the arm that makes the check skip the block entirely. Three things about it need stating. The fault is applied and removed around each step rather than around a pass. The first site to see a thread whose recorded stack pointer is wrong repairs that pointer on its way through, so a pass driven with one application of the fault covers the first site and nothing after it. Two sites look at the thread that is going to run rather than the one being operated on, and reaching them needs the two to differ. A time slice rotation leaves the peer as the thread to execute while the test thread is still the one running, which is the only arrangement that separates them; preemption is held off across the rotation and the service that follows it, because a tick in between would act on the rotation and the peer repairs itself on its way back. The threads that run while a thread identifier is cleared use the internal entry points. The error checking shell rejects such a block before the service behind it is reached, so a peer that relinquishes through the published entry point would stop relinquishing for as long as the fault is in place. The file also closes the two parts of the stack machinery no fault reaches: a create handed an odd stack address, which rounds it up and takes another word off the size, and the error handler's MISRA build, where there is no application handler to call and the function exists only to keep its argument referenced. The ten sites reach thirteen of fourteen, tx_thread_create.c and tx_thread_stack_error_handler.c reach 100%, and every tx_thread_* file is at 100% line. What is left in the batch is eighteen branch outcomes, all of them arms that need something the test side cannot produce: a null thread pointer at nine of the sites, which every caller of the scheduler makes impossible; the second check in _tx_thread_system_resume seeing a stack pointer the first one has already recorded; the sleep service's trace insert, which its own system state test puts out of reach at anything but thread level; and the trace update's "a later event overwrote this one", which needs an event inserted inside a window the kernel holds interrupts off across. Merged coverage over the six build configurations rises from 4097/4627 branches to 4140/4627 and from 4300/4339 lines to 4304/4339, identical across three clean runs. The gates go to 99.10 and 89.00. Assisted-by: Claude Code (Opus 5)

threadx.git/test/tx/regression/threadx_thread_stack_check_test.c, branch v6.4.1_cert

Covered the thread stack check's fault arms from the test side