APP stack backtrace missing (IDFGH-8672)

[ZhUyU1997]

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.

v4.4.2

Operating System used.

Linux

How did you build your project?

VS Code IDE

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

No response

Development Kit.

T-Display-S3

Power Supply used.

USB

What is the expected behavior?

I am a beginner in ESP32 and writing LCD drivers based on IDF.

static bool example_notify_lvgl_flush_ready(esp_lcd_panel_io_handle_t panel_io, esp_lcd_panel_io_event_data_t *edata, void *user_ctx)
{
    printf("example_notify_lvgl_flush_ready\n");
    return false;
}

  esp_lcd_panel_io_i80_config_t io_config = {
      .cs_gpio_num = PIN_LCD_CS,
      .pclk_hz = EXAMPLE_LCD_PIXEL_CLOCK_HZ,
      .trans_queue_depth = 20,
      .on_color_trans_done = example_notify_lvgl_flush_ready,
      .user_ctx = NULL, // TODO
      .lcd_cmd_bits = 8,
      .lcd_param_bits = 8,
      .dc_levels =
          {
              .dc_idle_level = 0,
              .dc_cmd_level = 0,
              .dc_dummy_level = 0,
              .dc_data_level = 1,
          },
  };

Indeed, it is incorrect, printf shouldn't be used on this callback.
But I don't know at first. UART doesn't give any useful information and keeps rebooting repeatedly.
I tried the steps in sequence.

• Turn off auto reboot
• Turn on the core dump
• Fix the libpython2.7 missing
• Analyze the core-dump
  Unfortunately, I still can't get any useful info except for exception PC

======================== THREADS INFO =========================
  Id   Target Id          Frame 
* 1    process 1070548836 0x420025a9 in panic_abort (details=0x3fc91b2b \"abort() was called at PC 0x40376beb on core 0\") at /home/yzhu/esp/esp-idf/components/esp_system/panic.c:402
  2    process 1070550724 0x4201b772 in esp_pm_impl_waiti () at /home/yzhu/esp/esp-idf/components/hal/esp32s3/include/hal/cpu_ll.h:182
  3    process 1070535836 0x4037a28c in xQueueSemaphoreTake (xQueue=0x3fcf0e40, xTicksToWait=<optimized out>) at /home/yzhu/esp/esp-idf/components/hal/esp32s3/include/hal/cpu_ll.h:38
  4    process 1070542436 0x400559e0 in ?? ()
  5    process 1070537988 xQueueSemaphoreTake (xQueue=0x3fcf16a8, xTicksToWait=<optimized out>) at /home/yzhu/esp/esp-idf/components/freertos/queue.c:1563
  6    process 1070546948 0x4037a0e9 in xQueueReceive (xQueue=0x3fce0bd8, pvBuffer=0x3fcf3c90, xTicksToWait=<optimized out>) at /home/yzhu/esp/esp-idf/components/hal/esp32s3/include/hal/cpu_ll.h:38

Why did we get this result? It is hard to analyze.
I have to trigger exception manually.

void __attribute__((noreturn)) esp_system_abort(const char *details)
{
    *((volatile int *) 0) = 0;
    panic_abort(details);
}

Then get a helpful backtrace as below. It is clean and enough.

==================== THREAD 1 (TCB: 0x3fcf4764, name: 'IDLE') =====================
#0  0x40379268 in esp_system_abort (details=0x3fc91b4b \"abort() was called at PC 0x40376c0b on core 0\") at /home/yzhu/esp/esp-idf/components/esp_system/esp_system.c:128
#1  0x4037f2f1 in abort () at /home/yzhu/esp/esp-idf/components/newlib/abort.c:46
#2  0x40376c0e in lock_acquire_generic (lock=0x3fc91c00, delay=4294967295, mutex_type=4 '\\004') at /home/yzhu/esp/esp-idf/components/newlib/locks.c:139
#3  0x40376d30 in _lock_acquire_recursive (lock=0x3fc91c00) at /home/yzhu/esp/esp-idf/components/newlib/locks.c:167
#4  0x40376dff in __retarget_lock_acquire_recursive (lock=<optimized out>) at /home/yzhu/esp/esp-idf/components/newlib/locks.c:323
#5  0x4200dda2 in _puts_r (ptr=0x3fcf47c4, s=<optimized out>) at /builds/idf/crosstool-NG/.build/xtensa-esp32s3-elf/src/newlib/newlib/libc/stdio/puts.c:89
#6  0x4200dde2 in puts (s=0x3c022edc \"example_notify_lvgl_flush_ready\") at /builds/idf/crosstool-NG/.build/xtensa-esp32s3-elf/src/newlib/newlib/libc/stdio/puts.c:129
#7  0x4200596d in example_notify_lvgl_flush_ready (panel_io=0x3fce08ac, edata=0x0, user_ctx=0x0) at /home/yzhu/esp32-s3-T-Display/fibonacci-app/main/main.c:52
#8  0x40376f81 in lcd_default_isr_handler (args=0x3fc95fbc) at /home/yzhu/esp/esp-idf/components/esp_lcd/src/esp_lcd_panel_io_i80.c:622
#9  0x40375eac in shared_intr_isr (arg=<optimized out>) at /home/yzhu/esp/esp-idf/components/esp_hw_support/intr_alloc.c:407
#10 0x40376964 in _xt_lowint1 () at /home/yzhu/esp/esp-idf/components/freertos/port/xtensa/xtensa_vectors.S:1111
#11 0x4201b75a in cpu_ll_waiti () at /home/yzhu/esp/esp-idf/components/hal/esp32s3/include/hal/cpu_ll.h:182
#12 esp_pm_impl_waiti () at /home/yzhu/esp/esp-idf/components/esp_pm/pm_impl.c:837
#13 0x4200c772 in esp_vApplicationIdleHook () at /home/yzhu/esp/esp-idf/components/esp_system/freertos_hooks.c:63
#14 0x4037a928 in prvIdleTask (pvParameters=0x0) at /home/yzhu/esp/esp-idf/components/freertos/tasks.c:3973
#15 0x4037c038 in vPortTaskWrapper (pxCode=0x4037a91c <prvIdleTask>, pvParameters=0x0) at /home/yzhu/esp/esp-idf/components/freertos/port/xtensa/port.c:131

So why we can't output it directly?
I request you to check the possibility.
Of course, whether the related configuration can be turned on by default is also a good question to improve the development experience

What is the actual behavior?

APP stack backtrace missing

Steps to reproduce.

1. Turn on the core dump
2. Invoke printf during callback of on_color_trans_done

Debug Logs.

No response

More Information.

No response

[igrr]

@ZhUyU1997 This looks like the same issue as #6124. It has been fixed in master (3556536) and in release/v5.0 (06cdc0e). In release/v4.4 branch the fix will be available in v4.4.4 bugfix release.

[ZhUyU1997]

@ZhUyU1997 This looks like the same issue as #6124. It has been fixed in master (3556536) and in release/v5.0 (06cdc0e). In release/v4.4 branch the fix will be available in v4.4.4 bugfix release.

Ok, I will check it once the new release is available.

[igrr]

The fix has been released in v4.4.4.