esp_ping_new_session does not work together with CONFIG_LWIP_CHECK_THREAD_SAFETY (IDFGH-14183)

[Tarik2142]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.3 a0f798c

Espressif SoC revision.

ESP32-D0WD-V3 (revision v3.0)

Operating System used.

Windows

How did you build your project?

Other (please specify in More Information)

If you are using Windows, please specify command line type.

CMD

Development Kit.

custom board

Power Supply used.

USB

What is the expected behavior?

esp_ping_new_session starts a new session

What is the actual behavior?

Panic reason: assert failed: netif_get_by_index /IDF/components/lwip/lwip/src/core/netif.c:1706 (Required to lock TCPIP core functionality!)

Steps to reproduce.

select LWIP_TCPIP_CORE_LOCKING
select LWIP_CHECK_THREAD_SAFETY
start new ping session

Debug Logs.

======================== THREADS INFO =========================
#0  0x400835f4 in panic_abort (details=0x3ffe17d4 "assert failed: netif_get_by_index /IDF/components/lwip/lwip/src/core/netif.c:1706 (Required to lock TCPIP core functionality!)") at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp_system/panic.c:463
#1  0x4008f1a4 in esp_system_abort (details=0x3ffe17d4 "assert failed: netif_get_by_index /IDF/components/lwip/lwip/src/core/netif.c:1706 (Required to lock TCPIP core functionality!)") at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp_system/port/esp_system_chip.c:92
#2  0x4009555d in __assert_func (file=<optimized out>, line=<optimized out>, func=<optimized out>, expr=<optimized out>) at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/newlib/assert.c:80
#3  0x4012943d in netif_get_by_index (idx=<optimized out>) at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/lwip/lwip/src/core/netif.c:1706
#4  netif_get_by_index (idx=3 '\003') at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/lwip/lwip/src/core/netif.c:1702
#5  0x4012946c in netif_index_to_name (idx=3 '\003', name=0x3ffe1910 "\004") at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/lwip/lwip/src/core/netif.c:1684
#6  0x4013b72f in esp_ping_new_session (config=0x3ffc483c <wg+20>, cbs=0x3ffc4878 <wg+80>, hdl_out=0x3ffc4888 <wg+96>) at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/lwip/apps/ping/ping_sock.c:263
#7  0x400d5d6b in WG::pingStart (this=0x3ffc4828 <wg>) at src/wg.h:99
#8  WG::wgTask (args=0x3ffc4828 <wg>) at src/wg.h:229
#9  0x4008ff3d in vPortTaskWrapper (pxCode=0x400d5c98 <WG::wgTask(void*)>, pvParameters=0x3ffc4828 <wg>) at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:139

More Information.

related issue espressif/arduino-esp32#10526

[david-cermak]

Hi @Tarik2142

There's a bug in the ping component, it calls potentially unsafe lwip API from the (user/esp_ping_new_session()) calling thread.
I'm attaching a possible fix:

lwip-Fix-ping-session-calling-thread-unsafe-API.path.txt

Thank you for reporting this issue, will fix!

[AxelLin]

Hi @david-cermak

I'm testing with esp-idf v5.2 branch: v5.2.3-902-g0bdb71f6b6
When I test ping with PPP interface, I got below assertion:

assert failed: xQueueSemaphoreTake queue.c:1709 (( pxQueue ))

Backtrace: 0x400818da:0x3ffc01b0 0x4008a5dd:0x3ffc01d0 0x40091bb1:0x3ffc01f0 0x4008adaa:0x3ffc0310 0x40112fc5:0x3ffc0350 0x40105f0c:0x3ffc0370 0x4011375a:0x3ffc03b0 0x400e92b8:0x3ffc03f0 0x400e500a:0x3ffc0450 0x400d7e97:0x3ffc04c0 0x401a1875:0x3ffc0500 0x401a1941:0x3ffc0550
--- 0x400818da: panic_abort at /home/axel/esp/esp-idf/components/esp_system/panic.c:466
0x4008a5dd: esp_system_abort at /home/axel/esp/esp-idf/components/esp_system/port/esp_system_chip.c:93
0x40091bb1: __assert_func at /home/axel/esp/esp-idf/components/newlib/assert.c:81
0x4008adaa: xQueueSemaphoreTake at /home/axel/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:1713 (discriminator 1)
0x40112fc5: sys_arch_sem_wait at /home/axel/esp/esp-idf/components/lwip/port/freertos/sys_arch.c:165
0x40105f0c: lwip_setsockopt at /home/axel/esp/esp-idf/components/lwip/lwip/src/api/sockets.c:3307
0x4011375a: setsockopt at /home/axel/esp/esp-idf/components/lwip/include/lwip/sockets.h:26
(inlined by) esp_ping_new_session at /home/axel/esp/esp-idf/components/lwip/apps/ping/ping_sock.c:304

It's 100% reproducible.
Note, revert 2e25510 fixed the issue.
Can you take a look and provide an urgent fix?
Thanks.

[david-cermak]

sorry for the regression, will merge the fix this week. here's the patch:

fix-lwip-Fix-potential-data-race-in-ping-tcpip-call.patch.txt

workaround is to set CONFIG_LWIP_NETIF_API=y

[AxelLin]

sorry for the regression, will merge the fix this week. here's the patch:

fix-lwip-Fix-potential-data-race-in-ping-tcpip-call.patch.txt

This fix works.

workaround is to set CONFIG_LWIP_NETIF_API=y

This workaround also works.

Thank you.