I am using FreeRTOS and i want to use mac protocol which i made !
On a single task, I want to Send_Beacon() function(send beacon frame).
When i call that function in task, there was a stack overflow.
void vApplicationStackOverflowHook(TaskHandle_t pxTask, char *pcTaskName)
vApplicationStackOverflowHook was called.
if (xTaskCreate(MAC_Init, (signed portCHAR *)"MAC_Inits", 128, NULL, 3,
NULL) == pdTRUE) {
//GPIOPinWrite(GPIO_C_BASE,GPIO_PIN_3,GPIO_PIN_3);
}
I had tried to change stack depth parameter from 128 to 1600.
It was failed.
What is the problem ?
Is not a problem about stack depth parameter's value ?
Remember the stack size is specified in words, not bytes. See the documentation of the xTaskCreate() and xTaskCreateStatic() functions.
If you are using xTaskCreate(), and cannot create the task after increasing its stack size, then you are running out of FreeRTOS heap (the link tells you what to do about it).
Related
Size of static storage area is constant throughout execution but dynamic stack grows and shrinks as per push and pop of activation record.
Storage requirements known prior to execution in static stack but int dynamic stack The size and structure of a stack frame is known at compile time, but actual contents and time of allocation is unknown until runtime.
What more can be the differences and can anyone help me with a code snippet.
Thank You.
I can chime in a bit here since I am currently working on a system that employs a kind of static stack.
Since you mentioned stack frames you must know that the stack is used to keep track of context when you enter deeper-nested subroutines. Just explicitly mentioning this b/c it is relevant in the next paragraph.
Typically the stack and heap are viewed as dynamic meaning that they are allowed to expand in size - usually done with memory management along the lines of malloc() etc. The classic illustration is show here (left panel). As you can see in the middle panel the stack grows + shrinks in a well-organized manner because memory can only be allocated or freed at the bottom edge. The heap, on the other hand, can see memory allocated / deallocated anywhere internally. A collision will occur when the two areas meet -- this will cause a big problem because no further subroutines can be called. Furthermore it can be hard to predict when this will happen.
If you want to avoid this kind of problem (for instance in a safety-critical application) you might opt to disallow dynamic memory usage in one or both of the stack + heap. A good time to use a static stack is when you are confident that your program will never exceed a particular depth of subroutine calls (e.g. no recursion, or recursion is capped). Using a static stack also simplifies the implementation, which is something that you might be concerned with on bare-metal applications.
The following code is a little example of how a static stack might be implemented in startup code:
//*****************************************************************************
//
// Reserve space for the system stack.
//
//*****************************************************************************
__attribute__ ((section(".stack")))
static uint32_t g_pui32Stack[1024];
The section attribute allows you to locate the stack in memory with the linker script:
ENTRY(Reset_Handler)
MEMORY
{
FLASH (rx) : ORIGIN = 0x0000C000, LENGTH = 960K
SRAM (rwx) : ORIGIN = 0x10000000, LENGTH = 384K
}
SECTIONS
{
.text :
{
/* This is where executable code gets stored */
} > FLASH
/* User stack section initialized by startup code. */
.stack (NOLOAD):
{
. = ALIGN(8);
*(.stack)
*(.stack*)
. = ALIGN(8);
} > SRAM
.data :
{
/* This is where global/static initialized variables are stored */
} > SRAM AT>FLASH
.bss :
{
/* This is where global/static 0-filled variables are stored */
} > SRAM
.heap (COPY):
{
/* This is where dynamically allocated storage could be used */
} > SRAM
}
You can see that in this case the stack is not located next to the heap... A static stack can be put wherever you want because the assumption is that you'll never go beyond its boundaries.
I have a few questions about Stack Guard and SSP protections. First question is about Stack Guard and its three types of canaries, if I am correctly - terminator, random and random XOR.
I'd like to know, how to disabled Stack Guard on x86 Linux system? Somewhere I read, it's possible with this command, while compiling with gcc '-disable-stackguard-randomization', it's same like with this command for enable '-enable-stackguard-randomization', both doesn't work. If needed, my gcc version is 4.8.2.
Next question about Stack guard, when I will able to enable/disable it, how can I set, which type of canaries I want to use? What I read, terminator canaries are used by default, for random I have to compiled with '-enable-stackguard-randomization', but how about random XOR? (Or with null 0x00000000)
Now about SSP(ProPolice), I know, for random canary I have to compiled with 'fstack-protector-all', but how about terminator, is it same as in Stack Guard, by default?
Last one, if anyone of you, can tell me, where I can find random canary in memory. For example, I have this scenario - compiled C program, like 'gcc -g example.c -o example -fstack-protector-all', so with random canaries. Let's say, I'm able to get address of canary, after every execution. So expect, I have: Canary = 0x1ae3f900. From a different papers, I get some info, that canary is located in .bss segment. So I get address of .bss segment using readelf: 'readelf -a ./example | grep bss'. It's 080456c9. In gdb I set some breakpoints, to get address of canary, but when I check .bss address x/20x 0x080456c9, all I see are only 0x00000000 addresses, but
canary is nowhere. Plus, I checked __stack_chk_fail's if it isn't there, but with same result, I can't see it there. I get address of stack_chk_fail from PLT/GOT.
Thank in advance for your answer and time.
Stack Smashing Protection (SSP) is an improvement over StackGuard. SSP was first implemented in gcc 4.1.
I'd like to know, how to disabled Stack Guard on x86 Linux system?
Use -fno-stack-protector to disable the userland SSP.
The --disable-stackguard-randomization and --enable-stackguard-randomization are build options for glibc source code.
when I will able to enable/disable it, how can I set, which type of
canaries I want to use?
This is not configurable in gcc as far as I know. Since glibc 2.10, the stack canary is generated in a function called _dl_setup_stack_chk_guard. Here is some part of its code:
if (dl_random == NULL)
{
ret.bytes[sizeof (ret) - 1] = 255;
ret.bytes[sizeof (ret) - 2] = '\n';
}
else
{
memcpy (ret.bytes, dl_random, sizeof (ret));
ret.num &= ~(uintptr_t) 0xff;
}
dl_random holds the address of the auxiliary vector entry for AT_RANDOM, which is a 16-byte random value initialized by the kernel while creating the process. If you are running on a kernel or an emulator that doesn't initialize AT_RANDOM, the check dl_random == NULL would be true and the canary used is the terminator value with the first and second most significant bytes initialized to 255 and \n, respectively. All other bytes are zero. Usually AT_RANDOM is initialized by the kernel and so the least 7 significant bytes of AT_RANDOM are copied. The last byte of canary is set to zero.
So if you want to use a particular method to generate the canary, you can change this code and build you own glibc.
As an alternative method, #PeterCordes have suggested in the comments to write your canary value to memory location %%fs:0x28 (see the code below) at the top of the main function and restore the runtime-generated canary just before returning from main.
Now about SSP(ProPolice), I know, for random canary I have to compiled
with 'fstack-protector-all', but how about terminator, is it same as
in Stack Guard, by default?
All variants of the -fstack-protector option use SSP. These don't affect how the canary is generated.
Last one, if anyone of you, can tell me, where I can find random
canary in memory.
The canary is generated dynamically early at process startup; you can't use readelf to get the canary. According to this article, you can use the following code to get the canary when compiling for i386:
int read_canary()
{
int val = 0;
__asm__("movl %%gs:0x14, %0;"
: "=r"(val)
:
:);
return val;
}
and for x86_64:
long read_canary()
{
long val = 0;
__asm__("movq %%fs:0x28, %0;"
: "=r"(val)
:
:);
return val;
}
I have written a function in C, which, when called, immediately results in a stack overflow.
Prototype:
void dumpOutput( Settings *, char **, FILE * );
Calling line:
dumpOutput( stSettings, sInput, fpOut );
At the time of calling it, stSettings is already a pointer to Settings structure, sInput is a dynamically allocated 2D array and fpOut is a FILE *. It reaches all the way to the calling line without any errors, no memory leaks etc.
The actual function is rather lengthy and i think its not worth sharing it here as the overflow occurs just as the code enters the function (called the prologue part, i think)
I have tried calling the same function directly from main() with dummy variables for checking if there are any problems with passed arguments but it still throws the stack overflow condition.
The error arises from the chkstk.asm when the function is called. This asm file (according to the comments present in it) tries to probe the stack to check / allocate the memory for the called function. It just keeps jumping to Find next lower page and probe part till the stack overflow occurs.
The local variables in dumpOutput are not memory beasts either, just 6 integers and 2 pointers.
The memory used by code at the point of entering this function is 60,936K, which increases to 61,940K at the point when the stack overflow occurs. Most of this memory goes into the sInput. Is this the cause of error? I don't think so, because only its pointer is being passed. Secondly, i fail to understand why dumpOutput is trying to allocate 1004K of memory on stack?
I am totally at a loss here. Any help will be highly appreciated.
Thanks in advance.
By design, it is _chkstk()'s job to generate a stack overflow exception. You can diagnose it by looking at the generated machine code. After you step into the function, right-click the edit window and click Go To Disassembly. You ought to see something similar to this:
003013B0 push ebp
003013B1 mov ebp,esp
003013B3 mov eax,1000D4h ; <== here
003013B8 call #ILT+70(__chkstk) (30104Bh)
The value passed through the EAX register is the important one, that's the amount of stack space your function needs. Chkstk then verifies it is actually available by probing the pages of stack. If you see it repeatedly looping then the value for EAX in your code is high. Like mine, it is guaranteed to consume all bytes of the stack. And more. Which is what it protects against, you normally get an access violation exception. But there's no guarantee, your code may accidentally write to a mapped page that belongs to, say, the heap. Which would produce an incredibly difficult to diagnose bug. Chkstk() helps you find these bugs before you blow your brains out in frustration.
I simply did it with this little test function:
void test()
{
char kaboom[1024*1024];
}
We can't see yours, but the exception says that you either have a large array as a local variable or you are passing a large value to _alloca(). Fix by allocating that array from the heap instead.
Most likely a stack corruption or recursion error but it's hard to answer without seeing any code
I am using the esp value of kernel stack to calculate the process descriptor pointer value.
According to ULK book, I just need to mask 13 least significant bits of esp to obtain the base address of the thread_info structure.
My test is:
write a kernel module because I need to get value of kernel stack
In the kernel init function, get the value of kernel stack
use following formula to get the process descriptor pointer of the process running on the CPU: *((unsigned int*) esp & 0xffffe000)
use the current macro, print out its value.
I think the value of step3 should be same as the value of step 4.
But my experiment results shows: sometimes they are same, and sometimes they are different. Could any explain why? Or am I missing anything?
This is because at the base of the kernel stack you will find a struct thread_info instance (platform dependent) and not a struct task_struct. The current() macro provides a pointer to the current task_struct.
Try the following:
struct thread_info *info = (struct thread_info*)(esp & 0xfffe000);
struct task_struct *my_current = info->task;
Now you can compare my_current with current().
Finally, I solved this problem. Everything is correct expect for the size of kernel stack. My kernel use 4KB stack instead of 8KB stack. So I just need to mask low 12 bits of the ESP.
Thanks for all the suggestions and answer!
Here is the project page
http://www.codeproject.com/KB/threads/StackWalker.aspx
[STACKFRAME64][1] s;
//s contains the current stack frame filled by calling [StackWalk64][2] WinAPI
if (s.AddrPC.Offset == s.AddrReturn.Offset)
{
printf("StackWalk64-Endless-Callstack!");
}
My question is when will this condition be satisfied? What addresses do s.AddrPC.Offset, s.AddrReturn.Offset contain?
Is the return address in the last frame on stack = 0?
Hopefully never, but it is a basic sanity check in case the stack frame got stomped. Which isn't unlikely when you try to walk the stack in an exception handler triggered by a nasty hardware exception like AccessViolation. Without that check the code would enter an endless loop, constantly finding the same stack frame back.
AddrPC is the address of the call instruction, AddrReturn is the return address, the address of the previous call instruction (+5). Not sure what "stack 0" might mean.