-
Notifications
You must be signed in to change notification settings - Fork 13.3k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Large stack usage in core and MDNS libraries #7398
Comments
That's a really nice feature. I just wonder, what does the parameter exactly state, as I cannot find the documentation on it right now. Most of the warnings I get are these:
Is it right to interpret these as the stack increase when entering the function? |
Those could be where you have an explicit
There are other warning options (stack-frame size) which I think ignore this kind of setup and only look for static size assignments, but I did not dig into it. |
Well I've been playing a bit more with this flag and I think it is a very good tool for the problems I'm seeing. This has been a good month.
And now the compiler telling me where I may run into stack overflows. I can only dream of what can be next... |
What stack decoder are you using ? |
@d-a-v
For this you need to have |
Latest master report:
|
I've been playing locally with GCC10 and the
-Wstack-usage=
option which emits a compile-time warning when stacks are larger than the size given. There's only 4K total stack to play with so I set the warning limit to 300 bytes.This isn't an exhaustive list (need to do a local CI and aggregate warnings), but I'm seeing very high use in the flash_hal and MDNS:
Flash_write() has a 512 byte buffer allocated on the stack in the case of an unaligned write, which seems pretty massive and ripe for reduction:
MDNS (old and new) have stack usages up to almost 700 bytes which might explain some issues seen at runtime.
Crypto.c has some large stacks (which might be unavoidable given the algorithm, but we may want to consider moving it to heap or refactoring the code:
The text was updated successfully, but these errors were encountered: