Closed moefear85 closed 2 years ago
Hi @moefear85 ,
Which IDF commit version are you using exactly? Do you have commit 09db8845c692ee5002810744fd1ce889d4d69c9d in your working tree?
@o-marshmallow
I THINK I'm using the march 11 commit of release/v4.4:
c29343eb94d2f2ca17b3a5b38c82452e556147f2
I can't try latest master. the version difference breaks so many things in my system so isn't working. But, I cloned using the following statement. I did it 2-3 days ago:
git clone --depth=1 --recursive --shallow-submodules -b releases/v4.4 https://github.com/espressif/esp-idf.git
If that doesn't automatically amount to the latest commit to that branch, then please inform me, as I would be using the wrong commit.
UPDATE: I just checked "git log", it clearly says I'm definately on the correct commit I thought I was.
At this point I have to ask... is there any sure way to know if any undetected heap corruption on the coder's side could still manage might systematically trigger the above exception at exactly the same function? It doesn't crash directly on the first run. Sometimes it runs on or two iterations (of being called). But I have heap corruption detection set to comprehensive, and stack smashing detection using canary bytes. I double & triple checked every malloc/new keyword to ensure it is matched with a delete statement through every possible branch of execution, and have everything structured so that it is simple to comprehend and follow. Other than that I make extensive use of nested C++ STL maps,vectors, and arrays whose top level maps are statically/globally defined. Moreover, the app runs indefinately over night and I've run it again and again over long periods of time. It doesn't crash at all. Only once I uncomment the above mentioned lines, it does, very very quickly.
I was writing past a heap buffer. I corrected it, now I'm not getting the error anymore. The irony though is, the whole point of calling heap_caps_check_integrity_all(true) is to catch such corruptions. I also have all memory/heap protections/debugging options set, but nothing caught it.
Environment
Problem Description
I'm trying to capture frames on an esp32-cam module. Everytime I call
it causes a panic.
Expected Behavior
I expect the functions to succeed, just like the other heap functions do. I can call these successfully:
Actual Behavior
once I uncomment the top mentioned functions, they fail, even if I use critical senctions or suspend everything else.
Code to reproduce this issue
Debug Logs
Other items if possible
sdkconfig.txt
Additional Info:
This seems related to 8658 as both involve the esp32s & heap issues. Btw I only see max about 90KB free memory at any moment. Is this usual/normal?
Also, could this commit be relevant?