[TW#13918] lwip/netconn: Memory leak for netconn_delete()

[devsaurus]

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?

[negativekelvin]

I believe if you are using netconn api you have to handle thread safety on your own, so you decide when to call netconn_free and call it yourself. Otherwise, use socket api.

[hwmaier]

This sounds familiar to the issue I mentioned here #537.

Make sure you do not use lwip_... calls as they are not automatically mapped to the thread safe counterparts.

[projectgus]

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

[devsaurus]

Thanks for the feedback, guys!

I exclusively use netconn_ calls so the handover between my single-task application (the NodeMCU Lua firmware) and the lwip stack should be safe. I assume that this is also true for calling netconn_free() after closing as Angus proposed.

Somewhat off-topic: I found that I strictly have to avoid calling netconn_ functions from the application callback in tcpip-task context (registered with netconn_new_with_callback()). This results in almost immediate stalls with I (81906) wifi: ap_probe_send over, resett wifi status to disassoc symptom.

[tonyp7]

I was getting crazy with this memory leak. Thank you for pointing me to this line 176!

[Ritesh236]

Hi,

We have also faced same memory leak issue while using netconn library at our side. so, what is the workaround or final fix for that issue?

We are using netconn open/close/accept/listen all those APIs into our project development purpose.

Please help us or any suggestions for that solution.

[tonyp7]

Add a call to netconn_free after netconn_delete.

[Ritesh236]

Ok. Let me check and get back to you with updated result.

[zhangyanjiaoesp]

@devsaurus @tonyp7 @Ritesh236 Sorry to reply so late, we have modified the code against your problem. After the MR is merged, you can see the change

[Ritesh236]

Hi, Thanks for Reply.

So, Will that fix be included into ESP32 LWIP Library in which netconn APIs are defined?

[zhangyanjiaoesp]

yes, it will be

[Ritesh236]

Hi, Thanks for providing update. It seems like you have fixed into ESP32 IDF on Git. Correct?

I will check it and let you know if any issue.

[Ritesh236]

Hi,

Also just want to confirm that now we don't need to call netconn_free after netconn_delete API as it has been fixed into LWIP code itself.

Correct?

[zhangyanjiaoesp]

@Ritesh236 yes, you are right

[Designer-Rick]

Well spotted on line 176!!! that was driving me crazy

[zhangyanjiaoesp]

@Designer-Rick Did you test with the latest esp-idf ? Please post your commit ID and your error log, thanks!