[x] I signed and emailed the appropriate Contributor License Agreement to GSFC-SoftwareRelease@mail.nasa.gov and copied cfs-program@lists.nasa.gov.
Describe the contribution
The glibc pthread implementation puts additional data structures at the base of the stack. The size of these is not known, but the only thing to go by is PTHREAD_MIN_STACK -- which should always be enough to hold the required objects.
Instead of simply assuring that the stack is at least PTHREAD_MIN_STACK, add this to the requested stack instead. This in turn will ensure that the user always has at least their requested stack size available for actual use.
If the pthread implementation does not advertise a PTHREAD_MIN_STACK value, then just reserve 1 extra page.
Fixes #1429
Testing performed
Execute all tests, execute CFE
Expected behavior changes
Internal stack size is now larger than requested in the API call, which compensates for the overhead used by pthreads itself.
System(s) tested on
Debian
Additional context
In testing this, the stack size for CFS apps in the cfe_es_startup.scr file was set at 8192 bytes. On the test system, PTHREAD_MIN_STACK was 16384.
Before the change, all CFS tasks were getting total stack of 16384 bytes (PTHREAD_MIN_STACK), but with almost 10kB already used when the entry point was invoked, thus only leaving about 6kB usable by the app. In this test, the MD app would sometimes overrun its stack, depending on how it loaded its tables.
After this change, the same CFS tasks now get 24576 bytes of total stack (PTHREAD_MIN_STACK + requested stack[8192]). This leaves about 14kB of usable stack, which more than the requested amount, and thus apps shouldn't overrun if the stack requirement is calculated correctly.
Contributor Info - All information REQUIRED for consideration of pull request
Joseph Hickey, Vantage Systems, Inc.
Checklist (Please check before submitting)
Describe the contribution The glibc pthread implementation puts additional data structures at the base of the stack. The size of these is not known, but the only thing to go by is PTHREAD_MIN_STACK -- which should always be enough to hold the required objects.
Instead of simply assuring that the stack is at least PTHREAD_MIN_STACK, add this to the requested stack instead. This in turn will ensure that the user always has at least their requested stack size available for actual use.
If the pthread implementation does not advertise a PTHREAD_MIN_STACK value, then just reserve 1 extra page.
Fixes #1429
Testing performed Execute all tests, execute CFE
Expected behavior changes Internal stack size is now larger than requested in the API call, which compensates for the overhead used by pthreads itself.
System(s) tested on Debian
Additional context In testing this, the stack size for CFS apps in the
cfe_es_startup.scrfile was set at 8192 bytes. On the test system,PTHREAD_MIN_STACKwas 16384.Before the change, all CFS tasks were getting total stack of 16384 bytes (
PTHREAD_MIN_STACK), but with almost 10kB already used when the entry point was invoked, thus only leaving about 6kB usable by the app. In this test, the MD app would sometimes overrun its stack, depending on how it loaded its tables.After this change, the same CFS tasks now get 24576 bytes of total stack (
PTHREAD_MIN_STACK+ requested stack[8192]). This leaves about 14kB of usable stack, which more than the requested amount, and thus apps shouldn't overrun if the stack requirement is calculated correctly.Contributor Info - All information REQUIRED for consideration of pull request Joseph Hickey, Vantage Systems, Inc.