Description
it seems very much that the cont stack is the root of a lot of stability issues.
I put a printf in the main loop did some testing:
after reset, rules disabled: 1600 bytes free.
after reset, rules enabled but empty: 1600 bytes free.
after reset, rules enabled, some rules that not fire: 1312-1296 bytes free.
------- using this config, push the notifications tab: 1188 bytes
------- hit edit: 1136 bytes free.
------- select email 624 bytes free.
if you want to get lower than that, use self-triggering rules. They drive the stack to 0. Not sure why.
The stack does never recover.
I tracked the memory loss to the spiffs write commands. Writing single bytes in a loop is worse than writing the whole bunch. (f.write(*ptr, size))
Once your low enough on stack the ESP gets all sort of exceptions pointing to various locations in the code. Kernel panic outputs I've seen too. I would suggest to
- find out what spiffs is doing with the stack. Is ist a bug ? Is there a workaround ?
- monitoring the stack and when it goes below 500 send a message. 500 is just good enough to leave a hint in a spiffs file and show it on the next occasion.
- in general: give the stack the same amount of attention like the free heap size.
- find out why self triggering rules ruin the stack totally. Are there maybe nested spiffs accesses ?
- show the stack size next to the free memory on the main page and include it in the checkram routine.