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

[mzimmers]

Hi all -

I'm trying to start an http_server (v3.3-rc) using the example in the docs. I'm getting an error:

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

I've traced it to this call to socket():

Code: Select all

// from the example:
httpd_handle_t HttpServer::start_webserver(void)
{
    /* Generate default configuration */
    httpd_config_t config = HTTPD_DEFAULT_CONFIG();
    /* Empty handle to esp_http_server */
    httpd_handle_t server = NULL;

    /* Start the httpd server */
    ESP_LOGI(TAG, "calling httpd_start().");
    if (httpd_start(&server, &config) == ESP_OK)

// from httpd_main.c
esp_err_t httpd_start(httpd_handle_t *handle, const httpd_config_t *config)
{
	...
	if (httpd_server_init(hd) != ESP_OK) {
	
static esp_err_t httpd_server_init(struct httpd_data *hd)
{
	int fd = socket(PF_INET6, SOCK_STREAM, 0);

Any ideas what I might be doing wrong?

Thanks...

[ESP_Angus]

The snippets of code you posted look OK to me, possibly the problem is being triggered by something else?

Can you please decode the backtrace addresses that lead up to the failed assertion, for some context? There are a lot of possible functions which can call xQueueGenericReceive().

[mzimmers]

Hi Angus -

Is this far enough? Thanks for looking at this.

Code: Select all

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:
PC      : 0x40091c64  PS      : 0x00060f30  A0      : 0x8018e0d9  A1      : 0x3ffb6f60
A2      : 0x00000000  A3      : 0x00000000  A4      : 0xffffffff  A5      : 0x00000000
A6      : 0x00000001  A7      : 0x00000005  A8      : 0x80091c61  A9      : 0x3ffb6ed0
A10     : 0x00000053  A11     : 0x00000053  A12     : 0x00000010  A13     : 0xffffffff
A14     : 0x00000000  A15     : 0xffffffeb  SAR     : 0x00000004  EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000040  LBEG    : 0x400014fd  LEND    : 0x4000150d  LCOUNT  : 0xfffffffe

ELF file SHA256: 4ac02226c96fee029767b71a97be5410af5ce88b75ccf957a89748a7cb3fa7b4

Backtrace: 0x40091c64:0x3ffb6f60 0x4018e0d6:0x3ffb6fa0 0x4018e3de:0x3ffb6fc0 0x40185dc4:0x3ffb6fe0 0x40185e2d:0x3ffb7000 0x4017c1ee:0x3ffb7020

$ addr2line -e build/WifiButton.elf 0x4018e3de
/Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/vfscanf.c:551

MZimmers@mzimmers-w10p MINGW32 /c/esp32_projects/wifibutton
$ addr2line -e build/WifiButton.elf 0x40185dc4
C:/esp-idf/components/lwip/lwip/src/core/ipv4/dhcp.c:911

MZimmers@mzimmers-w10p MINGW32 /c/esp32_projects/wifibutton
$ addr2line -e build/WifiButton.elf 0x40185e2d
C:/esp-idf/components/lwip/lwip/src/core/ipv4/dhcp.c:911

MZimmers@mzimmers-w10p MINGW32 /c/esp32_projects/wifibutton
$ addr2line -e build/WifiButton.elf 0x4017c1ee
C:/esp-idf/components/lwip/lwip/src/core/tcp_out.c:794 (discriminator 1)

MZimmers@mzimmers-w10p MINGW32 /c/esp32_projects/wifibutton
$ addr2line -e build/WifiButton.elf 0x4017d293
C:/esp-idf/components/lwip/lwip/src/core/udp.c:974 (discriminator 3)

MZimmers@mzimmers-w10p MINGW32 /c/esp32_projects/wifibutton
$ addr2line -e build/WifiButton.elf 0x4017a9a2
C:/esp-idf/components/lwip/lwip/src/api/api_msg.c:2010

[ESP_Sprite]

Hmm, that's not that informative... Can you try enabling heap poisining? Maybe something is drawing outside the lines of a buffer, overwriting a queue.

[ESP_Angus]

I agree with Sprite that it's probably something like that, and enabling the "heap poisoning" debugging feature may find it.

The other odd thing here is that the line numbers in the call stack don't seem to show a valid call stack for the LWIP included in IDF v3.3-rc. There are three possibilities I can think of:

- Submodule mismatch, so the LWIP source isn't the version included with 3.3-rc. This which may also explain the crash ("git submodule update --init --recursive" may be worthwhile just to be sure.)

OR

- There is a bug in the ESP32 gcc 5 toolchain that means line numbers shown by addr2line are sometimes inaccurate. Re-running addr2line and adding the flags -pfia may help (the function name is always correct even if the line number is off.) This is fixed in gcc 8.

OR

- Stack is being corrupted as well.

[mzimmers]

Hi guys -

Thanks for the ideas. I don't think this was a submodule mismatch; I'd already done the recursive submodule update.

Light heap poisoning was on, so I changed it to comprehensive. Here's the stack trace:

Code: Select all

MZimmers@mzimmers-w10p MINGW32 /c/esp32_projects/wifibutton
$ addr2line -pfia -e build/WifiButton.elf 0x40091c74
0x40091c74: xQueueGenericReceive at C:/esp-idf/components/freertos/queue.c:2038

MZimmers@mzimmers-w10p MINGW32 /c/esp32_projects/wifibutton
$ addr2line -pfia -e build/WifiButton.elf 0x4018e0d6
0x4018e0d6: sys_mutex_lock at C:/esp-idf/components/lwip/port/esp32/freertos/sys_arch.c:444

MZimmers@mzimmers-w10p MINGW32 /c/esp32_projects/wifibutton
$ addr2line -pfia -e build/WifiButton.elf 0x4018e3de
0x4018e3de: sys_arch_protect at C:/esp-idf/components/lwip/port/esp32/freertos/sys_arch.c:469

MZimmers@mzimmers-w10p MINGW32 /c/esp32_projects/wifibutton
$ addr2line -pfia -e build/WifiButton.elf 0x40185dc4
0x40185dc4: do_memp_malloc_pool at C:/esp-idf/components/lwip/lwip/src/core/memp.c:231

MZimmers@mzimmers-w10p MINGW32 /c/esp32_projects/wifibutton
$ addr2line -pfia -e build/WifiButton.elf 0x40185e2d
0x40185e2d: memp_malloc at C:/esp-idf/components/lwip/lwip/src/core/memp.c:231

MZimmers@mzimmers-w10p MINGW32 /c/esp32_projects/wifibutton
$ addr2line -pfia -e build/WifiButton.elf 0x4017c1ee
0x4017c1ee: netconn_alloc at C:/esp-idf/components/lwip/lwip/src/api/api_msg.c:1447 (discriminator 6)

MZimmers@mzimmers-w10p MINGW32 /c/esp32_projects/wifibutton
$ addr2line -pfia -e build/WifiButton.elf 0x4017d293
0x4017d293: netconn_new_with_proto_and_callback at C:/esp-idf/components/lwip/lwip/src/api/api_lib.c:935

MZimmers@mzimmers-w10p MINGW32 /c/esp32_projects/wifibutton
$ addr2line -pfia -e build/WifiButton.elf 0x4017a9a2
0x4017a9a2: lwip_socket at C:/esp-idf/components/lwip/lwip/src/api/sockets.c:3532

MZimmers@mzimmers-w10p MINGW32 /c/esp32_projects/wifibutton
$ addr2line -pfia -e build/WifiButton.elf 0x4016a6e1
0x4016a6e1: socket at C:/esp-idf/components/esp_http_server/src/httpd_main.c:113
 (inlined by) httpd_server_init at C:/esp-idf/components/esp_http_server/src/httpd_main.c:245

MZimmers@mzimmers-w10p MINGW32 /c/esp32_projects/wifibutton
$ addr2line -pfia -e build/WifiButton.elf 0x4016a9e6
0x4016a9e6: httpd_start at C:/esp-idf/components/esp_http_server/src/httpd_main.c:394 (discriminator 9)

Let me know if you want me to go further. Thanks...

[mzimmers]

Anyone have any ideas on this? Thanks...

[permal]

Just a thought, and I don't know if it applies to your set of IDF/compiler, but are you using PSRAM? Does it still happen if you disable it?

https://github.com/espressif/esp-idf/issues/2892

[mzimmers]

Hi Permal - thanks for the suggestion. I'm not sure I fully understand the problem...we're using the WROVER module in our product. How do I go about disabling PSRAM? I don't see a setting for it in my sdkconfig file.

Thanks...

[permal]

The Wrover does have PSRAM.

Component Config -> ESP32 Specific -> Support for external, SPI-connected RAM.