GDB internal error when attempting to access thread in dbg_coredump (IDFGH-575)

mill1000 commented 5 years ago

Environment

Development Kit: ESP32-DevKitC
Kit version (for WroverKit/PicoKit/DevKitC): v2
Module or chip used: ESP32-WROOM-32
IDF version: v3.1.2 release
Build System: Make
Compiler version: xtensa-esp32-elf-gcc.exe (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 5.2.0
Operating System: Windows
Power Supply: USB

Problem Description

When attempting to debug a coredump I have come across a task (thread) that I cannot access. I have tried updating espcoredump.py to the version that supports the ROM functions, and have been able to replicate the behavior in a minimal example.

I believe it is the FreeRTOS "Tmr Svc" task. All other tasks have been accounted for.

Expected Behavior

At very least I should be able to switch to the thread and see what the PC was.

Actual Behavior

GDB crashes

Steps to repropduce

Enable coredump to Flash
Cause a coredump
Run a dbg_coredump session
Run info threads

Code to reproduce this issue

#include <stdio.h>
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "sdkconfig.h"
#include "esp_log.h"

void blink_task(void *pvParameter)
{
    vTaskDelay(1000 / portTICK_PERIOD_MS);
    ESP_LOGI("Task", "Abort");
    abort();
}

void app_main()
{
    xTaskCreate(&blink_task, "blink_task", 1024, NULL, 5, NULL);
}

Debug Logs

$ python ../esp-idf/components/espcoredump/espcoredump.py dbg_corefile --core=blink.core build/blink.elf
GNU gdb (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-host_pc-mingw32 --target=xtensa-esp32-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from build/blink.elf...done.
[New <main task>]
[New process 1]
[New process 2]
[New process 3]
[New process 4]
[New process 5]
[New process 6]
#0  0x400864df in invoke_abort ()
    at esp-idf/components/esp32/panic.c:140
140             *((int *) 0) = 0;
[Current thread is 1 (<main task>)]
add symbol table from file "esp32_rom.elf" at
        .text_addr = 0x40000560
(y or n) [answered Y; input not from terminal]
Reading symbols from esp32_rom.elf...(no debugging symbols found)...done.
(gdb) info threads
  Id   Target Id         Frame
  7    process 6         0x4008537c in xQueueGenericReceive (
    xQueue=0x3ffafdb8 <r_modules_funcs+76>, pvBuffer=0x0,
    xTicksToWait=4294967295, xJustPeeking=0)
    at esp-idf/components/freertos/queue.c:1591
  6    process 5         0x4008537c in xQueueGenericReceive (
    xQueue=0x3ffaff84, pvBuffer=0x0, xTicksToWait=4294967295, xJustPeeking=0)
    at esp-idf/components/freertos/queue.c:1591
  5    process 4         0x4008537c in xQueueGenericReceive (
    xQueue=0x3ffaea30 <r_ip_funcs+800>, pvBuffer=0x0,
    xTicksToWait=4294967295, xJustPeeking=0)
    at esp-idf/components/freertos/queue.c:1591
  4    process 3
/builds/idf/crosstool-NG/.build/src/gdb-7.10/gdb/inline-frame.c:171: internal-error: inline_frame_this_id: Assertion `!frame_id_eq (*this_id, outer_frame_id)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]

This is a bug, please report it.  For instructions, see:
<http://www.gnu.org/software/gdb/bugs/>.

/builds/idf/crosstool-NG/.build/src/gdb-7.10/gdb/inline-frame.c:171: internal-error: inline_frame_this_id: Assertion `!frame_id_eq (*this_id, outer_frame_id)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]
espcoredump.py v0.2-dev
Done!

Other items if possible

Contains ELF, Coredump and sdkconfig blink.zip

igrr commented 5 years ago

Hi @mill1000, a workaround for this has been merged into master branch, but has not been backported to v3.1: https://github.com/espressif/esp-idf/commit/3ba63a520c91b961a2632ad7385c8bac9039e197. We will backport this, in the meantime you can try cherry-picking this commit to your branch of IDF.

mill1000 commented 5 years ago

@igrr, Ah excellent. I can confirm that cherry-picking 3ba63a5 resolves the issue and I can successfully access all the threads.

Any technical reason CONFIG_FREERTOS_TASK_FUNCTION_WRAPPER is tied to DEBUG optimization? I could use the wrappers in a Release build for better coredumps.

igrr commented 5 years ago

@mill1000 Yes, I think we can allow this in Release builds as well.

mill1000 commented 5 years ago

@igrr Should we close this now? Or wait for the backport? I'm not sure what your policy is.

espressif / esp-idf