Stopped the SMP stack check analyzing a stack it just found broken

[fdesbiens]

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:

                _tx_thread_stack_error_handler((thread_ptr));
                TX_DISABLE
            }
            if (*(((ULONG *) (thread_ptr) -> tx_thread_stack_highest_ptr) - 1) != TX_STACK_FILL)

So a thread whose stack has just been reported as corrupt goes straight on into _tx_thread_stack_analyze().

Why that is the wrong function to reach in that state

Analyzing a stack that is known to be broken is what _tx_thread_stack_analyze() 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 of the macro was given an else for exactly this reason. The SMP copy never was, and the two macros are otherwise identical, line for line — this single keyword was the whole of the divergence.

The path is live, not 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 SMP timeout

Worth stating plainly, since it would be easy to file this as the cause of the red suite. threadx_thread_priority_change never reaches the error handler at all, so whatever wedges it in teardown is something else (#647).

It is worth closing regardless. A runaway scan inside stack analysis would present as a test that stops producing output and is eventually killed — the shape that has been costing this suite whole runs — and it would be indistinguishable in the log from the hang already being chased.

Verification

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
• stack_checking_build and stack_checking_rand_fill_build both pass 110 of 110, repeated at the parallelism CI uses