Skip to content
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

POSIX Port: Round up stack sizes correctly on macOS #1161

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

hollinsky
Copy link

Description

On macOS, pthread_attr_setstacksize requires the stack size to be a multiple of the system page size.

The previous changes here assumed the use of pthread_attr_setstack, however the transition to pthread_attr_setstacksize means we can avoid rounding the pxEndOfStack pointer.

This is additionally positive because pxEndOfStack was actually being rounded in the wrong direction -- it ought to have been rounded down (_trunc) instead of up due to the stack growth direction. In my case this actually caused pxEndOfStack to end up after pxTopOfStack, which underflowed and created a huge stack size request + EXC_BAD_ACCESS in pthread_create.

Test Steps

I had a task with a 4kb stack which was causing the issue. Simply xTaskCreate with a 4kb stack on macOS and it will crash.

Checklist:

  • I have tested my changes. No regression in existing tests.
  • I have modified and/or added unit-tests to cover the code changes in this Pull Request.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

On macOS, pthread_attr_setstacksize requires the stack size to be a multiple of
the system page size.

The previous changes here assumed the use of pthread_attr_setstack, however
the transition to pthread_attr_setstacksize means we can avoid rounding the
pxEndOfStack pointer.

This is additionally positive because pxEndOfStack was actually being rounded
in the wrong direction -- it ought to have been rounded down (_trunc) instead of
up due to the stack growth direction. In my case this actually caused pxEndOfStack
to end up after pxTopOfStack, which underflowed and created a huge stack size
request + EXC_BAD_ACCESS in pthread_create.

Signed-off-by: Paul Hollinsky <[email protected]>
Copy link

sonarcloud bot commented Oct 20, 2024

@aggarg
Copy link
Member

aggarg commented Oct 21, 2024

Thank you for pointing this. Given that we are no longer using pthread_attr_setstack to use the application supplied memory as stack, I wonder if we should even call pthread_attr_setstacksize. May be can leave stack size to the default OS setting and can simplify the code like the following:

StackType_t * pxPortInitialiseStack( StackType_t * pxTopOfStack,
                                     StackType_t * pxEndOfStack,
                                     TaskFunction_t pxCode,
                                     void * pvParameters )
{
    Thread_t * thread;
    pthread_attr_t xThreadAttributes;
    int iRet;

    ( void ) pthread_once( &hSigSetupThread, prvSetupSignalsAndSchedulerPolicy );

    /*
     * Store the additional thread data at the start of the stack.
     */
    thread = ( Thread_t * ) ( pxTopOfStack + 1 ) - 1;
    pxTopOfStack = ( StackType_t * ) thread - 1;

    thread->pxCode = pxCode;
    thread->pvParams = pvParameters;
    thread->xDying = pdFALSE;

    pthread_attr_init( &xThreadAttributes );

    thread->ev = event_create();

    vPortEnterCritical();

    iRet = pthread_create( &thread->pthread, &xThreadAttributes,
                           prvWaitForStart, thread );

    if( iRet != 0 )
    {
        prvFatalError( "pthread_create", iRet );
    }

    vPortExitCritical();

    return pxTopOfStack;
}

What do you think?

@aggarg
Copy link
Member

aggarg commented Oct 22, 2024

@hollinsky Can you check if the above addresses the issue you are facing?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants