-
Notifications
You must be signed in to change notification settings - Fork 202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CFE_ES_CreateChildTask ignores its StackPtr argument #2516
Labels
Comments
jphickey
added a commit
to jphickey/cFE
that referenced
this issue
Feb 14, 2024
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.
2 tasks
jphickey
added a commit
to jphickey/cFE
that referenced
this issue
Feb 26, 2024
jphickey
added a commit
to jphickey/cFE
that referenced
this issue
Feb 26, 2024
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.
dzbaker
added a commit
that referenced
this issue
Mar 11, 2024
Fix #2516, propagate stack pointer for child tasks
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
The implementation of
CFE_ES_CreateChildTask()
does not correctly pass through the stack pointer, if this is used. As a result, the child task always uses a dynamically allocated stack, not the passed-in pointer.To Reproduce
Call
CFE_ES_CreateChildTask()
with a non-NULL stack pointer.The
CFE_ES_StartAppTask()
underlying function always usesOSAL_TASK_STACK_ALLOCATE
, not the passed-in pointer.Expected behavior
Should use the stack pointer provided by the user, if they pass one in.
System observed on:
Debian
Reporter Info
Joseph Hickey, Vantage Systems, Inc. (reporting on behalf of user/stakeholder bug report)
The text was updated successfully, but these errors were encountered: