esp-idf: [TW#13918] lwip/netconn: Memory leak for netconn_delete()
I’m evaluating the lwip netconn API and investigate some memory leaks with closed connections.
My application code assumes that a call to netconn_delete() finally frees all resources, but I observe that this is not true. I need to remove the #if !ESP_THREAD_SAFE in line 176 to get heap to return to initial level. Otherwise, each accept/send/close/delete cycle on a server netconn leaks ~70 bytes of heap memory. Similar for client connections.
What was the rationale to disable netconn_free() in case of ESP_THREAD_SAFE configuration? If it’s required, how to fix the memory leak when netconn_free() is not executed - Is there a thread-safe method to free it?
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 1
- Comments: 16 (4 by maintainers)
Commits related to this issue
- fixed a memory leak, see https://github.com/espressif/esp-idf/issues/784 — committed to tonyp7/esp32-wifi-manager by tonyp7 7 years ago
- when netconn created directly,netconn_delete() will not call netconn_free(), which will lead to memory leak Closes https://github.com/espressif/esp-idf/issues/784 — committed to espressif/esp-idf by zhangyanjiaoesp 7 years ago
- see https://github.com/espressif/esp-idf/issues/784 no longer necessary to call netcon_free since the memory leak was fixed with latest version of esp-idf — committed to tonyp7/esp32-wifi-manager by tonyp7 7 years ago
Hi @devsaurus ,
The thread-safe socket layer made this change in order to support closing a BSD socket from one thread while a pending read/write was running in another. This behaviour change for netconn_close() API looks like an unintended consequence.
Until we have a fix, the best workaround is probably to call netconn_free() after netconn_close().
Angus