Compiler not checking ram overflow in local variables?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-07-03 9:10 AM
Stm32CubeIDE v1.6.1
STM32 F1 library v1.8.4
New, empty project.
Something simple as this comples without any error or warning in a stm32f103.
It has 20KB ram, but for some reason the compiler doesn't care that I'm allocating 64KB!
Of course, it causes a hard fault. Declaring variable as global throws an error like it should.
void test(void){
volatile uint8_t dat[65536];
for(uint32_t t=0;t<sizeof(dat);t++){
dat[t]=GPIOA->IDR;
}
for(uint32_t t=0;t<sizeof(dat);t++){
GPIOB->ODR=dat[t];
}
}
- Labels:
-
DEBUG
-
STM32F1 Series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-07-03 9:26 AM
The compiler checks errors at compile time. So if you declare a variable as global it is allocated at compile time.
A local variable is allocated at run time from the stack. The compiler can't check this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-07-03 10:01 AM
So the only way is to use malloc and check for a valid pointer?
This variable is overwriting other existing memory! There's no way to check this at compile time?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-07-03 10:10 AM
You can use the stack analyzer in STM32CubeIDE to verify you're within whatever limit you set.
There's no runtime specific check that can be done here.
The call graph based usage is especially useful:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-07-03 10:12 AM
> So the only way is to use malloc and check for a valid pointer?
Malloc uses the heap, while defining a local variable uses the stack. They are different pools, but share the same space. Even if you get a valid pointer back from malloc, it could still be overwriting variables on the stack.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-07-03 10:15 AM
Yes, I can see the local cost. But how to ensure it fits when it's, ex. 1KB?
Some functions might be stacked, so also their stack sizes.
Anyways, how do I know if the system ram has enough space for it?
Maybe by adding the compiler ram usage report+function stack cost?
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-07-03 10:25 AM
> Anyways, how do I know if the system ram has enough space for it?
You manually check that the sum of the "max cost" of all IRQs that can be called at once is less than what you have allocated for your max stack size.
The call graph includes overhead for functions called by other functions. For example, Reset_Handler includes stack used by main(), as well as functions that main calls, and so on...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-07-03 10:32 AM
Thanks! Learned something really useful today! Feeling kinda stupid for such basic fault :face_with_tears_of_joy:
