Fix #2516, propagate stack pointer for child tasks #2517
Merged
+83
−13
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Checklist (Please check before submitting)
Describe the contribution
Update CFE_ES_CreateChildTask to propagate the user-supplied stack pointer to the underlying OS_TaskCreate call. Also adds a functional test to check that the memory address of a local variable within a child task resides within the expected stack buffer.
NOTE: this requires an additional fix to POSIX OSAL to make it work on that platform.
Fixes #2516
Testing performed
Build and run all tests
Expected behavior changes
CFE Child tasks created will adhere to passed-in stack pointer.
System(s) tested on
Debian, RTEMS
Additional context
The newly added functional test will fail on POSIX due to a similar bug in the OS_TaskCreate() implementation. This didn't propagate the stack pointer, either.
The biggest risk with "fixing" this is that it might expose stack size problems that were otherwise hidden. Many apps use very small stack sizes for child tasks, and on POSIX (at least Linux/Glibc) it puts TLS storage in the stack buffer. This TLS takes about 10kB off the top of the stack. If the entire stack was only 4kB, this is now a problem. It was hidden because POSIX created a stack anyway, and when it created the stack it was at least 16kB. But by fixing that problem, the stack size really will be only 4kB, and thus not be big enough, and memory corruption will result.
Contributor Info - All information REQUIRED for consideration of pull request
Joseph Hickey, Vantage Systems, Inc.