ESP-IDF v5.0 introducing " httpd_accept_conn: error in accept (23)"?

[mbratch]

I have an application running on ESP32 with the following features:

• HTTP REST API server
• OTA firmware update
• Optional logging to a syslog server

This was all working well when I was using ESP-IDF v4.4.2.

I decided to take the plunge and migrate to v5.0. I finally got it all working with very minimal changes and it seemed Ok. But I noticed that the application will "degrade" with use of the above listed features and start failing with errors:

Code: Select all

W (1245391) httpd: httpd_accept_conn: error in accept (23)
W (1245391) httpd: httpd_server: error accepting new connection

Or, alternatively, if I have logging turned on and attempt to open a socket, I get, ad infinitum (this is my message when an attempt to open a socket fails):

Code: Select all

W (33186) BD-PTB: Unable to create logging socket: (23) Too many open files in system
W (33711) BD-PTB: Unable to create logging socket: (23) Too many open files in system
W (34231) BD-PTB: Unable to create logging socket: (23) Too many open files in system
W (34746) BD-PTB: Unable to create logging socket: (23) Too many open files in system

It's tied in with the logging feature somehow. If I open and close the logging socket enough times, it seems they don't all get closed and eventually resources are gobbled up. If I turn off the logging altogether everything works fine. The logging works fine in ESP-IDF v4.4.2.

Sorry I don't have much more detail than that at the moment, but I wanted to know if anyone else has seen this. I'd like to resolve it if I can and stick with ESP-IDF v5.0, but I will need to revert to v4.4.2 (or perhaps v4.4.3) otherwise.

[Craige Hales]

I'd look for either a leak or memory fragmentation that prevents a large-enough block from being allocated. I used heap_caps_get_info to make a detailed report about memory issues. If the minimum heap is dropping below 50K or so, that might be an issue for the next allocation.

Screenshot_2022-12-22_07-55-30.png (73.49 KiB) Viewed 5013 times

[mbratch]

Thank you for the reply. I can check using `heap_caps_get_info`, but this application did not have a memory leak with v4.4.2 of the ESP-IDF, and going to v5.0 I didn't change the application. I have been running `heap_caps_get_free_size(MALLOC_CAP_8BIT)` and that's holding steady around 160k. I don't think my problem is a memory leak. I recall several months ago I had an issue with v4.4.x holding on to socket handles even after they were closed and I'd run out of them quickly. That problem was solved by setting an option or a patch somewhere (I don't recall what it was).

This case is a bit weird. I don't see any other evidence of an issue other than the ability to open any kind of Ethernet connection to/from the ESP32 is suddenly denied.

EDIT: I just checked minimum free heap and it's holding steady at 130k. If I can't make much headway on this, I'll just remove v5.0 and revert back to v4.4.2 and wait for v5.0 to mature a bit further.

After lots of test scenarios, I've determined that the problem only occurs when I do a couple of requests from a browser. I can do HTTP GET calls all day long from a program like Insomnia or Postman, and retrieve with GET any file on my SPIFFS partition, including javascript files. So there's something about what a web browser does in the requests that the ESP-IDF handler doesn't get along with. The web browser does a borage of GETs to different files, starting with the index.html. I did make sure that my maximum number of open files as sufficient for the request.

[ESP_YJM]

Hi mbratch
It seems the socket has run out. Some of the sockets enter TIME-WAIT state and can't be released immediately. You can enable enable_so_linger option in https://github.com/espressif/esp-idf/bl ... ver.h#L190. It will release the sockets immediately.

[axellin]

Hi mbratch
It seems the socket has run out. Some of the sockets enter TIME-WAIT state and can't be released immediately. You can enable enable_so_linger option in https://github.com/espressif/esp-idf/bl ... ver.h#L190. It will release the sockets immediately.

But why v4.4.x does not have this issue?

[mbratch]

It seems the socket has run out. Some of the sockets enter TIME-WAIT state and can't be released immediately. You can enable enable_so_linger option in https://github.com/espressif/esp-idf/bl ... ver.h#L190. It will release the sockets immediately.

Thanks for the suggestion!

Before I received this, I increased CONFIG_LWIP_MAX_SOCKETS from 10 to 16, and so far, after playing with it for several minutes and connected 3 clients, it seems to be holding up and not giving me the failure. I will need to do more testing, and may try the enable_so_linger if this doesn't prove a robust solution. I'm still a little puzzled why the issue started when I upgraded to ESP-IDF v5.0. Some performance aspects of v5.0 are (understandably) different I have seen in some cases.

[ESP_YJM]

Hi mbratch
It seems the socket has run out. Some of the sockets enter TIME-WAIT state and can't be released immediately. You can enable enable_so_linger option in https://github.com/espressif/esp-idf/bl ... ver.h#L190. It will release the sockets immediately.

But why v4.4.x does not have this issue?

I'm not sure about it. Maybe need enable SOCKET_DEBUG to check whether other components occupy the socket and not release.