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

[ehbar]

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.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.

1. 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
   

2. Observe the esp_console example runs as expected.
3. 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
   

4. 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]

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]

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.

[ESP-Marius]

As @suda-morris already mentioned, the problem is esp_ringbuf. ESP_STATIC_ANALYZER_CHECK was added to remove some static analyzer warning about null pointer dereferences that should never happen, but the logic was wrong.

We return pdFALSE if prvReceiveGeneric was called with any of the input pointers as NULL, but pvItem2 and xItemSize2 will only be non-null for split buffers...

We'll update this. thanks for the report.