FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [January 2008 Threads] Detecting stack overflowPosted by Michael Carr on January 22, 2008 Is there a way port.c could be easily modified to detect an overflow of the stack area allocated for each task, probably during context switching? Perhaps it could do this in a "checked" build and trigger a reset or an assertion of some other kind. At the moment, it's difficult to predict/detect such software stack overflows unless I observe that my system starts behaving strangely and then spend a lot of time isolating the problem.
RE: Detecting stack overflowPosted by Richard on January 22, 2008 It is fairly straight forward to prevent the scheduler writing over the end of the task stack as it knows where the stack start and end are.
It is a harder to *reliably* detect a task writing over the end of stack. A common technique is to put some known values at the end of the stack, then have the scheduler check that the known values are still there before switching to the next task - but this does not guarantee you will catch the fault as it is possible to write beyond the marker bytes without writing over the market bytes themselves.
Regards.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|