Crash when using opt-level="z" with esp32c6

[diekleinekuh]

Bug description

I have been experiencing weird crashes with an esp32c6 when using opt-level = "z". It crashes in log formatting when using #[derive(Debug)]. It doesn't crash with any other opt-level.

• Would you like to work on a fix? [n]

To Reproduce

1. Clone the minimal example repository I created
2. Use the devcontainer config provided when using vscode or install dependencies to develop for riscv esp chips and cargo-flash
3. run cargo espflash flash --monitor
4. Observe a crash

rst:0x15 (USB_UART_HPSYS),boot:0x48 (SPI_FAST_FLASH_BOOT)
Saved PC:0x40800822
SPIWP:0xee
mode:DIO, clock div:2
load:0x40875730,len:0x16f4
load:0x4086b910,len:0xed0
load:0x4086e610,len:0x319c
entry 0x4086b91a
I (23) boot: ESP-IDF v5.5.3 2nd stage bootloader
I (23) boot: compile time Apr  2 2026 11:56:18
I (24) boot: chip revision: v0.2
I (24) boot: efuse block revision: v0.3
I (26) boot.esp32c6: SPI Speed      : 80MHz
I (30) boot.esp32c6: SPI Mode       : DIO
I (34) boot.esp32c6: SPI Flash Size : 4MB
I (38) boot: Enabling RNG early entropy source...
I (42) boot: Partition Table:
I (45) boot: ## Label            Usage          Type ST Offset   Length
I (51) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (58) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (64) boot:  2 factory          factory app      00 00 00010000 00300000
I (71) boot: End of partition table
I (74) esp_image: segment 0: paddr=00010020 vaddr=42050020 size=281cch (164300) map
I (112) esp_image: segment 1: paddr=000381f4 vaddr=40800000 size=07e24h ( 32292) load
I (120) esp_image: segment 2: paddr=00040020 vaddr=42000020 size=4d8b0h (317616) map
I (179) esp_image: segment 3: paddr=0008d8d8 vaddr=40807e24 size=027c8h ( 10184) load
I (182) esp_image: segment 4: paddr=000900a8 vaddr=4080a5f0 size=02068h (  8296) load
I (187) boot: Loaded app from partition at offset 0x10000
I (188) boot: Disabling RNG early entropy source...
I (204) cpu_start: Unicore app
I (213) cpu_start: GPIO 17 and 16 are used as console UART I/O pins
I (213) cpu_start: Pro cpu start user code
I (213) cpu_start: cpu freq: 160000000 Hz
I (215) app_init: Application information:
I (219) app_init: Project name:     libespidf
I (223) app_init: App version:      8579d81
I (227) app_init: Compile time:     Apr  2 2026 11:56:12
I (232) app_init: ELF file SHA256:  000000000...
I (236) app_init: ESP-IDF:          v5.5.3
I (240) efuse_init: Min chip rev:     v0.0
I (244) efuse_init: Max chip rev:     v0.99 
I (248) efuse_init: Chip rev:         v0.2
I (252) heap_init: Initializing. RAM available for dynamic allocation:
I (258) heap_init: At 4080D690 len 0006EF80 (443 KiB): RAM
I (263) heap_init: At 4087C610 len 00002F54 (11 KiB): RAM
I (268) heap_init: At 50000000 len 00003FE8 (15 KiB): RTCRAM
I (274) spi_flash: detected chip: generic
I (277) spi_flash: flash io: dio
W (281) i2c: This driver is an old driver, please migrate your application code to adapt `driver/i2c_master.h`
I (290) sleep_gpio: Configure to isolate all GPIO pins in sleep state
I (296) sleep_gpio: Enable automatic switching of GPIO sleep configuration
I (312) main_task: Started on CPU0
I (312) main_task: Calling app_main()
Guru Meditation Error: Core  0 panic'ed (Instruction access fault). Exception was unhandled.

Core  0 register dump:
MEPC    : 0x85934200  RA      : 0x4203be3a  SP      : 0x40811670  GP      : 0x4080adf4  
0x4203be3a - <core::fmt::builders::DebugStruct>::field::{closure#0}
    at /home/esp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/builders.rs:133
0x4080adf4 - s_stub_table
    at ??:??
TP      : 0x40811910  T0      : 0x42011b56  T1      : 0x4200a2ce  T2      : 0x40811708  
0x42011b56 - <std::io::buffered::linewritershim::LineWriterShim<std::io::stdio::StdoutRaw> as std::io::Write>::write_all
    at /home/esp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/io/buffered/linewritershim.rs:296
0x4200a2ce - <std::io::default_write_fmt::Adapter<std::io::stdio::StdoutLock> as core::fmt::Write>::write_str
    at ??:??
S0/FP   : 0x408116c0  S1      : 0x00000001  A0      : 0x40811708  A1      : 0x4081171c  
A2      : 0x85934200  A3      : 0x00000020  A4      : 0x4087cd99  A5      : 0x4087cd99  
A6      : 0x4205639c  A7      : 0x420563be  S2      : 0x40811708  S3      : 0x42000172  
0x4205639c - $d
    at ??:??
0x420563be - $d
    at ??:??
0x42000172 - <my_test::A as core::fmt::Debug>::fmt
    at /workspaces/mytest/src/main.rs:6
S4      : 0x00000001  S5      : 0x420563be  S6      : 0x4081171c  S7      : 0x00000001  
0x420563be - $d
    at ??:??
S8      : 0x42000172  S9      : 0x00000000  S10     : 0x60000020  S11     : 0xffffffff  
0x42000172 - <my_test::A as core::fmt::Debug>::fmt
    at /workspaces/mytest/src/main.rs:6
T3      : 0x00000000  T4      : 0x00000000  T5      : 0x00000000  T6      : 0x00000000  
MSTATUS : 0x00001881  MTVEC   : 0x40800001  MCAUSE  : 0x00000001  MTVAL   : 0x85934200  
0x40800001 - _vector_table
    at /workspaces/mytest/.embuild/espressif/esp-idf/v5.5.3/components/riscv/vectors_intc.S:54
MHARTID : 0x00000000  

Stack memory:
40811670: 0xa5a5a5a5 0x00000000 0x4080ac74 0x4201a44e 0x00000000 0x4080ac74 0x4080ac70 0x4205639c
0x4080ac74 - std::io::stdio::STDOUT
    at ??:??
0x4201a44e - <std::io::stdio::StdoutLock as std::io::Write>::write_all
    at ??:??
0x4080ac74 - std::io::stdio::STDOUT
    at ??:??
0x4080ac70 - std::io::stdio::STDOUT
    at ??:??
0x4205639c - $d
    at ??:??
40811690: 0x420563be 0x4081171c 0x40811768 0x40811708 0x00000001 0x00000001 0x40811818 0x4205639c
0x420563be - $d
    at ??:??
0x4205639c - $d
    at ??:??
408116b0: 0x420563be 0x4081171c 0x420563bd 0x42039546 0x4081171c 0x00000100 0x4200a2a2 0x00000001
0x420563be - $d
    at ??:??
0x420563bd - $d
    at ??:??
0x42039546 - <core::fmt::Formatter>::debug_struct_field2_finish
    at /home/esp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:2477
0x4200a2a2 - <std::io::default_write_fmt::Adapter<std::io::stdio::StdoutLock> as core::fmt::Write>::write_str
    at /home/esp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/io/mod.rs:627
408116d0: 0x420526af 0x40811768 0x40811820 0x4206c144 0x42058530 0x000000c0 0x420526ae 0x420001c0
0x4206c144 - $d
    at ??:??
0x42058530 - $d
    at ??:??
0x420526ae - $d
    at ??:??
0x420001c0 - OUTLINED_FUNCTION_0
    at ??:??
408116f0: 0x00000001 0x40811708 0x42000172 0x00000000 0x00000000 0x4087d1c0 0x4081181c 0x420397e0
0x42000172 - <my_test::A as core::fmt::Debug>::fmt
    at /workspaces/mytest/src/main.rs:6
0x420397e0 - core::fmt::write
    at /home/esp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:1686
40811710: 0x00000000 0x4087d1c0 0x4087d1d0 0x40811768 0x42058530 0x60000020 0x00000000 0x00000000
0x42058530 - $d
    at ??:??
40811730: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x408117d8
40811750: 0x408117ac 0x00000004 0x408117d8 0x42009168 0x00000001 0x00000001 0x4080dd04 0x40800dc8
0x42009168 - std::io::default_write_fmt::<std::io::stdio::StdoutLock>
    at /home/esp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/io/mod.rs:639
0x40800dc8 - heap_caps_aligned_alloc_base
    at /workspaces/mytest/.embuild/espressif/esp-idf/v5.5.3/components/heap/heap_caps_base.c:177
40811770: 0x408117ac 0x40811820 0x420526ae 0x4201a4f4 0x00000000 0x420526ae 0x40811820 0x00000000
0x420526ae - $d
    at ??:??
0x4201a4f4 - <std::io::stdio::StdoutLock as std::io::Write>::write_fmt
    at ??:??
0x420526ae - $d
    at ??:??
40811790: 0x40811820 0x420526ae 0x408117d8 0x4201a41e 0x00000000 0x00000000 0x00000000 0x4080ac58
0x420526ae - $d
    at ??:??
0x4201a41e - <&std::io::stdio::Stdout as std::io::Write>::write_fmt
    at ??:??
0x4080ac58 - std::io::stdio::STDOUT
    at ??:??
408117b0: 0x408118a0 0x420526ae 0x40811820 0x4201a3f0 0x408118a0 0x420526ae 0x408117e4 0x4201a280
0x420526ae - $d
    at ??:??
0x4201a3f0 - <std::io::stdio::Stdout as std::io::Write>::write_fmt
    at ??:??
0x420526ae - $d
    at ??:??
0x4201a280 - std::io::stdio::print_to::<std::io::stdio::Stdout>
    at /home/esp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/io/stdio.rs:1164
408117d0: 0x4205e8fa 0x00000006 0x4080dd04 0x40800dc8 0x00001800 0x4080ac58 0x0000000c 0x00000004
0x4205e8fa - $d
    at ??:??
0x40800dc8 - heap_caps_aligned_alloc_base
    at /workspaces/mytest/.embuild/espressif/esp-idf/v5.5.3/components/heap/heap_caps_base.c:177
0x4080ac58 - std::io::stdio::STDOUT
    at ??:??
408117f0: 0x00000001 0x00000000 0x00000000 0x00000003 0x00001800 0x408118c8 0x420526ae 0x420000d8
0x420526ae - $d
    at ??:??
0x420000d8 - my_test::main
    at /workspaces/mytest/src/main.rs:31
40811810: 0x00000001 0x4087cd6c 0x00000001 0x42044f08 0x40811818 0x42000150 0x40811888 0x4200009e
0x42044f08 - find_key
    at /workspaces/mytest/.embuild/espressif/esp-idf/v5.5.3/components/pthread/pthread_local_storage.c:79
0x42000150 - <my_test::A as core::fmt::Debug>::fmt
    at /workspaces/mytest/src/main.rs:6
0x4200009e - std::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()>
    at /home/esp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/backtrace.rs:172
40811830: 0x408118a0 0x4080c66c 0x00000000 0x42000090 0x408118a0 0x00000000 0x40811888 0x4200ffd6
0x4080c66c - $d
    at ??:??
0x42000090 - OUTLINED_FUNCTION_0
    at ??:??
0x4200ffd6 - std::panicking::catch_unwind::do_call::<&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe, i32>
    at /home/esp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:581
40811850: 0x408118a0 0x00000000 0x00000000 0x408118c8 0x42050124 0x408118c8 0x42050124 0x4200ff64
0x42050124 - $d
    at ??:??
0x42050124 - $d
    at ??:??
0x4200ff64 - <core::result::Result<i32, alloc::boxed::Box<dyn core::any::Any + core::marker::Send>>>::unwrap_or_else::<std::rt::lang_start_internal::{closure#0}::{closure#0}>
    at /home/esp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/result.rs:1620
40811870: 0x00000000 0x408118c8 0x42050124 0x00000000 0x420563d4 0x4080dd00 0x00000000 0x42072670
0x42050124 - $d
    at ??:??
0x420563d4 - $d
    at ??:??
40811890: 0x00000000 0x00000000 0x42072000 0x42019fb8 0x408118d4 0x00000000 0x408118c8 0x42050124
0x42019fb8 - <core::result::Result<isize, alloc::boxed::Box<dyn core::any::Any + core::marker::Send>>>::unwrap_or_else::<std::rt::handle_rt_panic<isize>>
    at /home/esp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/result.rs:1620
0x42050124 - $d
    at ??:??
408118b0: 0x00000000 0x420563d4 0x4080dd00 0x4200006c 0x420725fc 0x00000138 0x420000a4 0x4204d640
0x420563d4 - $d
    at ??:??
0x4200006c - std::rt::lang_start::<()>
    at /home/esp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:211
0x420000a4 - my_test::main
    at /workspaces/mytest/src/main.rs:22
0x4204d640 - main_task
    at /workspaces/mytest/.embuild/espressif/esp-idf/v5.5.3/components/freertos/app_startup.c:209
408118d0: 0x00000000 0x00001388 0x00000001 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
408118f0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
40811910: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0x00000150 0x40811870 0x00000000 0x4080c930 0x4080c930
0x4080c930 - pxReadyTasksLists
    at ??:??
0x4080c930 - pxReadyTasksLists
    at ??:??
40811930: 0x40811920 0x4080c928 0x00000018 0x00000000 0x00000000 0x40811920 0x00000000 0x00000001
0x4080c928 - pxReadyTasksLists
    at ??:??
40811950: 0x4080f71c 0x6e69616d 0x00000000 0x00000000 0x00000000 0x40811910 0x00000001 0x00000001
40811970: 0x4087cd6c 0x42044f30 0x00000000 0x4080dfdc 0x4080e044 0x4080e0ac 0x00000000 0x00000000
0x42044f30 - pthread_cleanup_thread_specific_data_callback
    at /workspaces/mytest/.embuild/espressif/esp-idf/v5.5.3/components/pthread/pthread_local_storage.c:126
40811990: 0x00000001 0x00000000 0x00000000 0x00000000 0x420448a0 0x00000000 0x00000000 0x00000000
0x420448a0 - esp_cleanup_r
    at /workspaces/mytest/.embuild/espressif/esp-idf/v5.5.3/components/newlib/src/newlib_init.c:42
408119b0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
408119d0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
408119f0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
40811a10: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
40811a30: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
40811a50: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000



ELF file SHA256: 000000000

Rebooting...

I also tested again the git version by adding this to Cargo.toml with the same effect:

[patch.crates-io]
esp-idf-sys = { git = "https://github.com/esp-rs/esp-idf-sys.git" }
esp-idf-hal = { git = "https://github.com/esp-rs/esp-idf-hal.git" }
esp-idf-svc = { git = "https://github.com/esp-rs/esp-idf-svc.git" }

Expected behavior

The example should not crash but print:

...
I (305) main_task: Calling app_main()
A { a: 1, m: B }
C { a: 2, m: D }
I (305) main_task: Returned from app_main()

Environment

• esp-idf-svc: 0.52.1 or git, older versions too
• OS: Debian GNU/Linux 12
• MCU="esp32c6"
• ESP_IDF_VERSION = "v5.5.3"

When I change opt-level to anything else the crash doesn't occur. Also slightly changing the logged structs or removing the call to esp_idf_svc::sys::link_patches() removes the crash.

I found an old issue that sounded similar.
rust-embedded/cortex-m#503

When adding the proposed rust flag "-Cllvm-args=--enable-machine-outliner=never" the crash also doesn't occur.

I'm not sure if this is the right place to report the issue or if this is a bug in rust or llvm.

[ivmarkov]

@diekleinekuh Thank you so much for reporting this!

The thing is, I have only experienced this in a large project which furthermore uses esp-hal (baremetal) and not the esp-idf-* crates.
I was also unable to reproduce it so far with a minimum example.

Now - and if I remember correctly - it only happened with "Debug" log level (which is normal as then that other large project logs a lot) and only with debug/dev builds - where - as you can see - I use opt-level "z" just like you.

But the fact that this happens with the esp-idf-* crates too likely means this is indeed a mis-compilation issue in rustc or llvm.

(Or - I hope much less likely - some oddity of my coding style which has introduced a similar bug in both the esp-idf-* crates as well as in the rs-matter-* crates and which only happens for RiscV.)

@bugadani JFYI - have you guys stumbled on this when working on esp-hal?

As for "-Cllvm-args=--enable-machine-outliner=never" making it disappear - interesting. I thought the original problem was fixed already, but maybe it was only fixed for cortex-m indeed (for me this happens for riscv32imac; not sure if also for riscv32imc, but definitely not for cortex-m or xtensa)

[diekleinekuh]

I also tested this on a xtensa esp32 and it didn't crash. What also hints a bit at a compiler issue is that when creating the example code I could trigger a crash at the first log statement by adding code after it. So adding code that isn't even executed causes a crash at an earlier place.

I also tested upgrading clang and used the nightly build but that didn't seem to change anything.

[ivmarkov]

I also tested this on a xtensa esp32 and it didn't crash.

Yes. xtensa is not affected, only riscv

I also tested upgrading clang and used the nightly build but that didn't seem to change anything.

clang is not really used in this setup, if at all. The rust code is compiled by rustc (+ llvm) and the C code - by GCC.
And moreover, in my other project using esp-hal GCC is not even used and ditto for clang. It is really rustc/llvm

[diekleinekuh]

I also tested upgrading clang and used the nightly build but that didn't seem to change anything.

clang is not really used in this setup, if at all. The rust code is compiled by rustc (+ llvm) and the C code - by GCC. And moreover, in my other project using esp-hal GCC is not even used and ditto for clang. It is really rustc/llvm

I was using clang by uninstalling gcc and mapping clang-23 to cc using update-alternatives. But since it's not used in your scenario and had no effect in mine it can be ruled out.

Regarding -Cllvm-args=--enable-machine-outliner :

I noticed that not only adding -Cllvm-args=--enable-machine-outliner=never will fix the crash when using opt-level = "z" but also adding -Cllvm-args=--enable-machine-outliner=always will introduce the crash on all other values for opt-level (except 0 which probably disables all optimizations in general).

[ivmarkov]

I was using clang by uninstalling gcc and mapping clang-23 to cc using update-alternatives. But since it's not used in your scenario and had no effect in mine it can be ruled out.

The system GCC is never, ever used for embedded targets with the esp-idf-* crates or any others. After all, GCC is not a cross-compiler, so the system GCC cannot be used anyway.

During cargo build, esp-idf-sys itself downloads the correct GCC cross-toolchain for xtensa or riscv. I'm just mentioning this as FYI if you look inside the .embuild folder of your project, you'll see what is automatically downloaded during the build.

I was using clang by uninstalling gcc and mapping clang-23 to cc using update-alternatives. But since it's not used in your scenario and had no effect in mine it can be ruled out.

Regarding -Cllvm-args=--enable-machine-outliner :

I noticed that not only adding -Cllvm-args=--enable-machine-outliner=never will fix the crash when using opt-level = "z" but also adding -Cllvm-args=--enable-machine-outliner=always will introduce the crash on all other values for opt-level (except 0 which probably disables all optimizations in general).

@bugadani @MabezDev FYI ^^^ I think we should come up with esp-idf-*-independent repro and then report upstream.