(solved) getting "assert failed" on socket() call

[mzimmers]

Ah. Thank you. That is currently not enabled for my project, so I guess that wasn't it. Still good to know about that issue, though.

[ESP_Angus]

Thanks for the updated stack trace. Interestingly, this one is a little different to the last one - but roughly the same.

The allocator inside LWIP calls lwip's sys_arch_protect function which calls this:

Code: Select all

sys_prot_t
sys_arch_protect(void)
{
  sys_mutex_lock(&g_lwip_protect_mutex);
  return (sys_prot_t) 1;
}

(g_lwip_protect_mutex is a static mutex, initialized during LWIP initialization.)

The crash in FreeRTOS makes it look like this mutex is not initialized (or more likely, has been corrupted and overwritten with NULL).

Do you have assertions disabled, by any chance? https://docs.espressif.com/projects/esp ... tion-level

Asking as I would expect an assertion failure instead of this crash.

However, the root cause is probably the same in both cases - something is corrupting memory, maybe another static buffer in your code is overflowing and overwriting g_lwip_protect_mutex.

Suggest trying selectively disabling startup code and see if this crash goes away. You can also look at the output of "xtensa-esp32-elf-nm -n build/https_request.elf " and see what variable is allocated immediately before "g_lwip_protect_mutex", when sorted by address (the -n option).

[mzimmers]

Hi Angus -

I believe I *am* getting an assertion failure -- here's the start of the console output:

C:/esp-idf/components/freertos/queue.c:1442 (xQueueGenericReceive)- assert failed!
Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled.
Core 0 register dump:

Also, I'm calling the http startup very early in my program:

Code: Select all

extern "C" void app_main()
{
    HttpServer httpServer;
    httpd_handle_t httpHandle;

    ESP_LOGI(TAG, "entering app_main()");

    // start the web server.
    ESP_LOGI(TAG, "starting webserver.");
    httpHandle = httpServer.start_webserver();
    ...

I can try disabling startup code, but it wouldn't seem that would make much sense in this case.

[mzimmers]

OK, I have some more information that may be useful. I put in log statements prior to where the program blows up; they should be semi-self-explanatory:

I (357) HTTP_SERVER: calling httpd_start().
I (367) httpd: entering httpd_start().
I (367) httpd: calling httpd_create().
I (377) httpd: calling httpd_server_init().
I (377) httpd: calling socket().
I (377) LWIP: entering lwip_socket().
I (387) LWIP: lwip_socket(): calling netconn_new_with_callback().
I (397) api_lib: netconn_new_with_proto_and_callback(): calling netconn_alloc().
I (397) netconn_alloc: calling memp_malloc().
I (407) memp_malloc: starting.
I (407) memp_malloc: calling do_memp_malloc_pool().
I (417) do_memp_malloc_pool: calling mem_malloc().
I (417) do_memp_malloc_pool: call to mem_malloc() returned 3ffb9724.
I (427) do_memp_malloc_pool: calling SYS_ARCH_PROTECT().
I (437) sys_arch: sys_arch_protect(): calling sys_mutex_lock with 0.

So, as far as I can see, the problem is that sys_mutex_lock() is being called before sys_mutex_new(). The argument to sys_mutex_lock() is therefore NULL, and general hilarity ensues.

So...can someone tell me what (if anything) I can do about this?

Thanks.

[ESP_Angus]

Ah, sorry I should have checked this before: app_main() needs to call tcpip_adapter_init() before doing anything with sockets, or LWIP is not initialized. Actually it's advised to also call nvs_flash_init().

Consult any of the "protocols" examples for a basic initialization call flow for calling these two functions in app_main().

[mzimmers]

Oh, I should have realized that. Thanks, Angus. That problem has gone away, and the HTTP server seems to be running fine now.