POSIX implementation does not adhere to user-specified stack pointer #1449
Assignees
Labels
Comments
jphickey
added a commit
to jphickey/osal
that referenced
this issue
Feb 14, 2024
When the OS_TaskCreate() function is called with a non-NULL stack pointer, the POSIX implementation now should use this pointer as intended. Previously it was always allocating a new stack buffer, ignoring the passed-in pointer. NOTE: When using this feature, the caller must use caution to make sure the buffer being passed in is large enough to use as a task stack. Particularly when running under a desktop Linux/Glibc environment, the infrastructure puts a considerably large object on the stack. For example, in the osal-core-tests, the stack size was too small.
2 tasks
dzbaker
added a commit
that referenced
this issue
Feb 22, 2024
Fix #1449, POSIX implementation honors stack pointer
2 tasks
jphickey
added a commit
to jphickey/osal
that referenced
this issue
Feb 26, 2024
dzbaker
added a commit
that referenced
this issue
Feb 29, 2024
Fix #1449, POSIX implementation honors stack pointer
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
The
OS_TaskCreate()function accepts a stack pointer argument. Per the API, if this is not NULL, it is supposed to be used as the stack pointer for the newly-created task. VxWorks and RTEMS implement this, but POSIX ignores this argument. Currently, the POSIX implementation will allocate a stack buffer, regardless of what was passed in.Describe the solution you'd like
Should adhere to the passed-in stack pointer argument.
Additional context
POSIX does define a function for this -
pthread_attr_setstack().Related issue in CFE: nasa/cFE#2516 ... when validating that fix, noticed that the newly-added tests fail on POSIX, because it does not adhere to the stack pointer.
Requester Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: