Patterns for heap corruption resolution ...

[cmorgan]

Hi @ESP_Angus, any ideas? This is blocking hardware from being released into the field, I can't release it without knowing that this won't occur during normal use.

[ESP_Angus]

Not really, sorry. Heap corruption can be very tricky to debug for this reason!

Despite the WiFi stack traces in the heap dumps, my gut feeling is that these are a symptom of the corruption (as WiFi uses heap regularly), rather than the cause. If they were the cause, we'd see these crashes in our own stress tests or in other users' bug reports.

All I can advise is to look very closely at all the HTTP server handler code and cJSON usage. And add even more heap_caps_check_integrity() calls if you can - if you can narrow down a window of time where "heap is OK at this point in time, then bad at this later point in time" then you can start to move the checks and narrow this window down until you find the precise point in time when the heap becomes corrupt.

[cmorgan]

Ok. I'll keep at it here. I agree that it is likely in some code on my side. If you run across something latent and remember this thread please let me know. I'll post when I know more.

[ESP_Angus]

Hi cmorgan,

There is a buffer overflow bug fixed in cJSON 1.7.1 (we are currently using 1.6.0). Reported by permal here:
https://github.com/espressif/esp-idf/issues/1577

Fix coming ASAP.

You may also find this thread interesting:
https://esp32.com/viewtopic.php?f=2&t=4583&p=19928