Min Heap Threshold Callback? "OOM Killer"?

[p-rimes]

Hi there,

Wondering whether there is some feature in esp-idf to execute a (user-provided) callback when a low memory condition is reached?

Such that -- for example -- we can have application code that runs when heap reaches 10KB remaining, and in that case select a task and delete it (or make some attempt to reclaim memory other than rebooting, perhaps disabling some other features).

[ESP_Angus]

No, there's no built-in feature. Suggest adding a timer callback with a regular free memory check and whatever response makes sense in that particular firmware.

One difficulty for an "OOM Killer" type approach, compared to Linux, is that ESP32 has no memory protection. Killing a task only frees that task's stack memory, and doesn't otherwise clean anything up (network resources, memory, FreeRTOS resources/lock state, etc).

[p-rimes]

No, there's no built-in feature. Suggest adding a timer callback with a regular free memory check and whatever response makes sense in that particular firmware.

One difficulty for an "OOM Killer" type approach, compared to Linux, is that ESP32 has no memory protection. Killing a task only frees that task's stack memory, and doesn't otherwise clean anything up (network resources, memory, FreeRTOS resources/lock state, etc).

That's pretty much what I have for now, a recurring timer using a combo of `heap_caps_get_per_task_info` and `uxTaskGetSnapshotAll` to determine heap/stack usage of each task. I do have a messaging layer (ringbufs) between tasks which can trigger a task to delete itself (which, through C++ RAII will free/release all the allocated resources).

However, my worry is that the timer approach won't be able to respond fast enough to react to a series of large allocations e.g. starting a TLS connection (the biggest typical offender in my apps). I suppose I was hoping for a feature that wrapped `malloc` or interacted with the heap tracking / heap-poisoning stuff, if this could be considered a feature request?

[ESP_igrr]

trigger a task to delete itself (which, through C++ RAII will free/release all the allocated resources

Keep in mind that FreeRTOS vTaskDelete does no unwind stack frames, and does not cause destructors of local variables to be called.
You may, however, throw a C++ exception from the place where the task receives OOM message, and catch it in the task function, calling vTaskDelete afterwards.

[p-rimes]

trigger a task to delete itself (which, through C++ RAII will free/release all the allocated resources

Keep in mind that FreeRTOS vTaskDelete does no unwind stack frames, and does not cause destructors of local variables to be called.
You may, however, throw a C++ exception from the place where the task receives OOM message, and catch it in the task function, calling vTaskDelete afterwards.

Good to know! I hope I'm catching your meaning, but this would only apply if I try to vTaskDelete a different task that is still in the middle of running? In my case the xTaskCreate/vTaskDelete happen within C++ constructors/destructors (the task function gets access to the 'this' pointer through userdata), and the instance is added to a static unordered_map (with all the other created tasks). So when erasing from the task map, vTaskDelete is always the last command that gets run within the destructor. Hope this is still alright, what would the implications be?