mirror of
https://github.com/eclipse-threadx/threadx.git
synced 2026-10-06 06:59:08 +08:00
Frédéric DesbiensandClaude Opus 5
c8d27c4e25
TX_THREAD_STACK_CHECK detects a broken stack, calls the error handler, and then
tests whether the word below the high-water mark still holds the fill pattern.
On the SMP side that second test is a plain if, so a thread whose stack has
just been reported as corrupt goes straight on into _tx_thread_stack_analyze().
Analyzing a stack that is known to be broken is what that function is least
able to do. It binary searches between stack_lowest and stack_highest for the
fill pattern and then scans forward with
while (*stack_ptr == TX_STACK_FILL)
which has no bound of its own and no reason to terminate once the pattern it is
looking for is no longer where the pointers say it should be. The non-SMP copy
was given an else for exactly this reason. The SMP copy never was, and the two
macros are otherwise identical, line for line, so this single keyword was the
whole of the divergence.
The path is live in CI rather than theoretical. Instrumenting the internal
handler and running all 110 binaries of stack_checking_build shows
threadx_thread_stack_checking_test reaching it four times per run, on a thread
whose stack the test corrupts on purpose. Every one of those four currently
falls through into the analyze it should be skipping.
This is not the timeout the SMP suite has been failing on.
threadx_thread_priority_change never reaches the error handler at all, so
whatever wedges it in teardown is something else. Worth closing regardless: a
runaway scan inside stack analysis would present as a test that stops producing
output and is eventually killed, which is the shape that has been costing this
suite whole runs, and it would be indistinguishable in the log from the hang
already being chased.
Verified on both configurations that define TX_ENABLE_STACK_CHECKING.
threadx_thread_stack_checking_test, the one test that exercises the changed
branch, passes 60 consecutive runs, and stack_checking_build and
stack_checking_rand_fill_build both pass 110 of 110, repeated at the
parallelism CI uses.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>