Setting CONFIG_COMPILER_STATIC_ANALYZER=y causes basic console example to crash (IDFGH-14094)

ehbar commented 2 hours ago

Answers checklist.

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

IDF version.

v5.4-dev-4291-g7a305c0284

Espressif SoC revision.

ESP32-S3 (QFN56) (revision v0.2)

Operating System used.

Linux

How did you build your project?

Command line with idf.py

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

None

Development Kit.

ESP32-S3-DevKitC-1-N8R8

Power Supply used.

USB

What is the expected behavior?

The "basic" esp_console example at https://github.com/espressif/esp-idf/tree/master/examples/system/console/basic executes normally

What is the actual behavior?

The "basic" esp_console example at https://github.com/espressif/esp-idf/tree/master/examples/system/console/basic panics at start if the kconfig option CONFIG_COMPILER_STATIC_ANALYZER=y is set (!).

Steps to reproduce.

In a fresh copy of the master branch of esp-idf, run:

cd examples/system/console/basic
idf.py build && idf.py flash && idf.py monitor

Observe the esp_console example runs as expected.

Now enable CONFIG_COMPILER_STATIC_ANALYZER (which as far as I can see just adds -fanalyze to the compiler):

idf.py menuconfig
# Search for and enable CONFIG_COMPILER_STATIC_ANALYZER
# Save settings and exit
idf.py build && idf.py flash && idf.py monitor

Observe the system panics in a loop due to an assertion at components/esp_driver_uart/src/uart_vfs.c:299.

Debug Logs.

Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x40375e20
--- 0x40375e20: esp_restart_noos at /home/eric/src/github.com/espressif/esp-idf/components/esp_system/port/soc/esp32s3/system_internal.c:160

SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce2820,len:0x1120
load:0x403c8700,len:0x4
load:0x403c8704,len:0xb2c
load:0x403cb700,len:0x2d40
entry 0x403c88a8
I (204) cpu_start: Multicore app
I (213) cpu_start: Pro cpu start user code
I (213) cpu_start: cpu freq: 160000000 Hz
I (213) app_init: Application information:
I (213) app_init: Project name:     console
I (217) app_init: App version:      v5.4-dev-4291-g7a305c0284
I (222) app_init: Compile time:     Nov 17 2024 22:21:42
I (227) app_init: ELF file SHA256:  b5276594c...
I (232) app_init: ESP-IDF:          v5.4-dev-4291-g7a305c0284
I (237) efuse_init: Min chip rev:     v0.0
I (241) efuse_init: Max chip rev:     v0.99 
I (245) efuse_init: Chip rev:         v0.2
I (249) heap_init: Initializing. RAM available for dynamic allocation:
I (255) heap_init: At 3FCA4E50 len 000448C0 (274 KiB): RAM
I (260) heap_init: At 3FCE9710 len 00005724 (21 KiB): RAM
I (265) heap_init: At 3FCF0000 len 00008000 (32 KiB): DRAM
I (270) heap_init: At 600FE120 len 00001EC8 (7 KiB): RTCRAM
I (277) spi_flash: detected chip: gd
I (279) spi_flash: flash io: dio
W (282) spi_flash: Detected size(8192k) larger than the size in the binary image header(4096k). Using the size in the binary image header.
I (294) sleep_gpio: Configure to isolate all GPIO pins in sleep state
I (301) sleep_gpio: Enable automatic switching of GPIO sleep configuration
I (307) main_task: Started on CPU0
I (317) main_task: Calling app_main()
I (327) example: Command history enabled

assert failed: uart_read uart_vfs.c:299 (c != NONE)

Backtrace: 0x40375ee1:0x3fca9670 0x4037e875:0x3fca9690 0x40387265:0x3fca96b0 0x42009731:0x3fca97d0 0x4200cb4a:0x3fca97f0 0x42082d2a:0x3fca9810 0x4200c153:0x3fca9830 0x4200cb4a:0x3fca9850 0x42082d2a:0x3fca9870 0x420159e6:0x3fca9890 0x42014d27:0x3fca98c0 0x420161bf:0x3fca98e0 0x4200d5e8:0x3fca9930 0x420976b7:0x3fca9980 0x4037f3ad:0x3fca99b0
--- 0x40375ee1: panic_abort at /home/eric/src/github.com/espressif/esp-idf/components/esp_system/panic.c:454
0x4037e875: esp_system_abort at /home/eric/src/github.com/espressif/esp-idf/components/esp_system/port/esp_system_chip.c:92
0x40387265: __assert_func at /home/eric/src/github.com/espressif/esp-idf/components/newlib/assert.c:80
0x42009731: uart_read at /home/eric/src/github.com/espressif/esp-idf/components/esp_driver_uart/src/uart_vfs.c:299 (discriminator 1)
0x4200cb4a: esp_vfs_read at /home/eric/src/github.com/espressif/esp-idf/components/vfs/vfs.c:922 (discriminator 4)
0x42082d2a: read at /builds/idf/crosstool-NG/.build/xtensa-esp-elf/src/newlib/newlib/libc/syscalls/sysread.c:11 (discriminator 1)
0x4200c153: console_read at /home/eric/src/github.com/espressif/esp-idf/components/esp_vfs_console/vfs_console.c:94
0x4200cb4a: esp_vfs_read at /home/eric/src/github.com/espressif/esp-idf/components/vfs/vfs.c:922 (discriminator 4)
0x42082d2a: read at /builds/idf/crosstool-NG/.build/xtensa-esp-elf/src/newlib/newlib/libc/syscalls/sysread.c:11 (discriminator 1)
0x420159e6: linenoiseProbe at /home/eric/src/github.com/espressif/esp-idf/components/console/linenoise/linenoise.c:1090
0x42014d27: esp_console_setup_prompt at /home/eric/src/github.com/espressif/esp-idf/components/console/esp_console_common.c:26
0x420161bf: esp_console_new_repl_uart at /home/eric/src/github.com/espressif/esp-idf/components/console/esp_console_repl_chip.c:255
0x4200d5e8: app_main at /home/eric/src/github.com/espressif/esp-idf/examples/system/console/basic/main/console_example_main.c:107
0x420976b7: main_task at /home/eric/src/github.com/espressif/esp-idf/components/freertos/app_startup.c:208
0x4037f3ad: vPortTaskWrapper at /home/eric/src/github.com/espressif/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:139

More Information.

Yes, this is extremely bizarre, but I can 100% reproduce the panic on three different devices: a generic/no-name esp32 chip rev v3.1, and two different esp32s3 boards I have including an an Espressif ESP32-S3-DevKitC-1-N8R8.

The panic is triggered after the linenoise library tries on init to send an ANSI escape code to the terminal and read its response.

As far as I can tell, CONFIG_COMPILER_STATIC_ANALYZER=y just adds the -fanalyzer flag to GCC when compiling, which I don't think is supposed to change the build artifact. So this could be a compiler bug.

ehbar commented 2 hours ago

Output of $HOME/.espressif/tools/xtensa-esp-elf/esp-14.2.0_20240906/xtensa-esp-elf/bin/xtensa-esp32s3-elf-gcc --version:

xtensa-esp-elf-gcc (crosstool-NG esp-14.2.0_20240906) 14.2.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

suda-morris commented 1 hour ago

Thanks for the detailed report, we can reproduce it as well.

AFAICT, it's like a bug introduced by ESP_STATIC_ANALYZER_CHECK in the esp-idf. If I comment out the ESP_STATIC_ANALYZER_CHECK in the esp_ringbuf/ringbuf.c, the example just works as expected.

espressif / esp-idf