search

espressif / esp-idf

Espressif IoT Development Framework. Official development framework for Espressif SoCs.
Apache License 2.0
12.89k stars 7.08k forks source link

Executing espcoredump.py results in an Error in path (parsing) (IDFGH-7943) #9458

Open ddomnik opened 1 year ago

ddomnik commented 1 year ago

Environment

Problem Description

Via sdkconfig, I enabled the Core dump Data destination: Flash Core dump data format: ELF format and also tested Binary format Core dump data integrity check: Use CRC32 ... [x] Check core dump data integrity on boot Maximum number of task: 64

I provoked an error so:

Guru Meditation Error: Core  0 panic'ed (LoadProhibited). Exception was unhandled.

Core  0 register dump:
PC      : 0x4200d2a4  PS      : 0x00060f30  A0      : 0x8200b3de  A1      : 0x3fcf3db0
0x4200d2a4: initServices() at C:/Users/XXX/Documents/esp/XXX/src/OS/os_wrapper/cfg/TaskCfg.cpp:211

A2      : 0x00000000  A3      : 0x00000002  A4      : 0x00000001  A5      : 0x381f8000
A6      : 0x3fce06f4  A7      : 0x00000000  A8      : 0x00000000  A9      : 0x3fcf3d60
A10     : 0x00000001  A11     : 0x3c10649c  A12     : 0x3c1064a0  A13     : 0x000003b9
A14     : 0x3c10649c  A15     : 0x00000000  SAR     : 0x00000007  EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000004  LBEG    : 0x400556d5  LEND    : 0x400556e5  LCOUNT  : 0xfffffffe

Backtrace:0x4200d2a1:0x3fcf3db00x4200b3db:0x3fcf3dd0 0x420fa257:0x3fcf3df0 0x40380c69:0x3fcf3e20
0x4200d2a1: initServices() at C:/Users/XXX/Documents/esp/XXX/src/OS/os_wrapper/cfg/TaskCfg.cpp:207

0x4200b3db: app_main at C:/Users/XXX/Documents/esp/XXX/main/main.cpp:6

0x420fa257: main_task at C:/Espressif/frameworks/esp-idf-master/components/freertos/FreeRTOS-Kernel/portable/port_common.c:124 (discriminator 2)

0x40380c69: vPortTaskWrapper at C:/Espressif/frameworks/esp-idf-master/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:141

ELF file SHA256: aa133302135f4d3f

I (1018) esp_core_dump_flash: Save core dump to flash...
I (1024) esp_core_dump_flash: Erase flash 12288 bytes @ 0x670000
I (1186) esp_core_dump_flash: Write end offset 0x2ea4, check sum length 4
I (1186) esp_core_dump_flash: Core dump has been saved to flash.
CPU halted.

After that I run inside the ESP-IDF 5.0 PowerShell espcoredump.py -p COM5 info_corefile C:\Users\XXX\Documents\esp\XXX\build\XXX.elf a new window opens that immediately closes. I tried to catch it, but the only thing I got was in the screenshot attached. Error in path (parsing) -> tot_len

I also tried to edit the espcoredump.py and add input() to debug it but had no luck (maybe someone can help here)

Expected Behavior

Show info from core dump

core_dump_elf

ddomnik commented 1 year ago

Some additional information: I tried to use espcoredump.py directly from VS Code with a launch.json for passing the args as so:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: Current file",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal",
            "args": ["-p", "COM5", "info_corefile", "C:/Users/XXX/Documents/esp/XXX/build/XXX.elf"]
        }
    ]
}

When running it, an error in the gen_esp32part.py file arises, no matter if the core dump gets saved as binary or elf to the flash.

Exception has occurred: UnicodeDecodeError
'utf-8' codec can't decode byte 0x83 in position 0: invalid start byte
  File "C:\Espressif\frameworks\esp-idf-master\components\partition_table\gen_esp32part.py", line 426, in from_binary
    res.name = res.name.decode()
  File "C:\Espressif\frameworks\esp-idf-master\components\partition_table\gen_esp32part.py", line 279, in from_binary
    result.append(PartitionDefinition.from_binary(data))
  File "C:\Espressif\frameworks\esp-idf-master\components\partition_table\parttool.py", line 116, in __init__
    partition_table = gen.PartitionTable.from_binary(f.read())
  File "C:\Espressif\frameworks\esp-idf-master\components\partition_table\parttool.py", line 334, in main
    target = ParttoolTarget(**target_args)
  File "C:\Espressif\frameworks\esp-idf-master\components\partition_table\parttool.py", line 365, in <module>
    main()

core_dump_vscode

ddomnik commented 1 year ago

When trying to decode it via a copied UART print and run info_corefile, I get this error (added more prints to espcoredump.py ):

espcoredump.py v1.2
===============================================================
====================     LOAD CORE DUMP    ====================
==================== ESP32 CORE DUMP START ====================

Crashed task handle: 0x3fcf3f24, name: '', GDB name: 'process 1070546724'

================== CURRENT THREAD REGISTERS ===================
exccause       0x1c (LoadProhibitedCause)
excvaddr       0x4
epc1           0x0
epc2           0x0
epc3           0x0
epc4           0x0
epc5           0x0
epc6           0x0
epc7           0x0
eps2           0x0
eps3           0x0
eps4           0x0
eps5           0x0
eps6           0x0
eps7           0x0

==================== CURRENT THREAD STACK =====================
[New process 1070546724]
[New process 1070548612]
[New process 1070550500]
[New process 1070536284]
[New process 1070542212]
[New process 1070537660]
[New process 1070552900]
[Current thread is 1 (process 1070546724)]

======================== THREADS INFO =========================

Traceback (most recent call last):
  File "C:\Espressif\frameworks\esp-idf-master\components\espcoredump\espcoredump.py", line 76, in <module>
    main()
  File "C:\Espressif\frameworks\esp-idf-master\components\espcoredump\espcoredump.py", line 61, in main
    temp_core_files = espcoredump.info_corefile()
  File "C:\Users\ddomnik\AppData\Local\Programs\Python\Python310\lib\site-packages\esp_coredump\coredump.py", line 363, in info_corefile
    self.print_threads_info(task_info)
  File "C:\Users\ddomnik\AppData\Local\Programs\Python\Python310\lib\site-packages\esp_coredump\coredump.py", line 209, in print_threads_info
    threads, _ = self.gdb_esp.get_thread_info()
  File "C:\Users\ddomnik\AppData\Local\Programs\Python\Python310\lib\site-packages\esp_coredump\corefile\gdb.py", line 100, in get_thread_info
    current_thread_id = result['current-thread-id']
TypeError: 'NoneType' object is not subscriptable

Command: espcoredump.py --chip esp32s3 info_corefile -t b64 -c <coredump_uart_file> <project.elf>

ddomnik commented 1 year ago

The above error ('NoneType' object is not subscriptable) occurs also in a minimal example project.

Project:

#include "freertos/FreeRTOS.h"
#include <string.h>
#include <esp_log.h>
#include "esp_partition.h"

/* SDK Configuration
 *
 * Component config > Core dump:
 *      Destination: Flash
 *      Format: Binary
 *      Check integrity: YES
 *      Max num. of task: 64
 *
 * Component config > ESP System Settings:
 *      Panic handler behaviour: Print registers and halt
 *
 */

COREDUMP_DRAM_ATTR uint8_t global_var;

void app_main(void)
{
    ESP_LOGI("X","START");

    global_var = 25;

    assert(0);
}

Partition table:

# ESP-IDF Partition Table
# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x9000,  0x6000,
phy_init, data, phy,     0xf000,  0x1000,
factory,  app,  factory, 0x10000, 1M,
coredump, data, coredump,0 110000,64K

Core dump command: espcoredump.py -p COM5 info_corefile C:\Users\ddomnik\Documents\esp\coredump\build\coredump.elf

Result:

espcoredump.py v1.2
===============================================================
====================     LOAD CORE DUMP    ====================
INFO: Invoke parttool to read image.
INFO: esptool.py v4.1
Serial port COM5
Connecting....
Detecting chip type... ESP32-S3
Chip is ESP32-S3
Features: WiFi, BLE
Crystal is 40MHz
MAC: 34:b4:72:70:0b:78
Uploading stub...
Running stub...
Stub running...
3072 (100 %)
3072 (100 %)
Read 3072 bytes at 0x00008000 in 0.3 seconds (81.1 kbit/s)...
Hard resetting via RTS pin...
esptool.py v4.1
Serial port COM5
Connecting....
Detecting chip type... ESP32-S3
Chip is ESP32-S3
Features: WiFi, BLE
Crystal is 40MHz
MAC: 34:b4:72:70:0b:78
Uploading stub...
Running stub...
Stub running...
65536 (100 %)
65536 (100 %)
Read 65536 bytes at 0x00110000 in 6.1 seconds (86.2 kbit/s)...
Hard resetting via RTS pin...
Running C:\Users\ddomnik\AppData\Local\Programs\Python\Python310\python.exe C:\Espressif\frameworks\esp-idf-master\components\esptool_py\esptool\esptool.py --port COM5 read_flash 32768 3072 C:\Users\ddomnik\AppData\Local\Temp\tmp2p35go1z...
Running C:\Users\ddomnik\AppData\Local\Programs\Python\Python310\python.exe C:\Espressif\frameworks\esp-idf-master\components\esptool_py\esptool\esptool.py --port COM5 read_flash 1114112 65536 C:\Users\ddomnik\AppData\Local\Temp\tmpipwey48n...
Read partition 'coredump' contents from device at offset 0x110000 to file 'C:\Users\ddomnik\AppData\Local\Temp\tmpipwey48n'

==================== ESP32 CORE DUMP START ====================

Crashed task handle: 0x3fcf3acc, name: '', GDB name: 'process 1070545612'

================== CURRENT THREAD REGISTERS ===================
exccause       0x1d (StoreProhibitedCause)
excvaddr       0x0
epc1           0x0
epc2           0x0
epc3           0x0
epc4           0x0
epc5           0x0
epc6           0x0
epc7           0x0
eps2           0x0
eps3           0x0
eps4           0x0
eps5           0x0
eps6           0x0
eps7           0x0

==================== CURRENT THREAD STACK =====================
[New process 1070545612]
[New process 1070547500]
[New process 1070549388]
[New process 1070535060]
[New process 1070540884]
[New process 1070536436]
[Current thread is 1 (process 1070545612)]

======================== THREADS INFO =========================

Traceback (most recent call last):
  File "C:\Espressif\frameworks\esp-idf-master\components\espcoredump\espcoredump.py", line 76, in <module>
    main()
  File "C:\Espressif\frameworks\esp-idf-master\components\espcoredump\espcoredump.py", line 61, in main
    temp_core_files = espcoredump.info_corefile()
  File "C:\Users\ddomnik\AppData\Local\Programs\Python\Python310\lib\site-packages\esp_coredump\coredump.py", line 363, in info_corefile
    self.print_threads_info(task_info)
  File "C:\Users\ddomnik\AppData\Local\Programs\Python\Python310\lib\site-packages\esp_coredump\coredump.py", line 209, in print_threads_info
    threads, _ = self.gdb_esp.get_thread_info()
  File "C:\Users\ddomnik\AppData\Local\Programs\Python\Python310\lib\site-packages\esp_coredump\corefile\gdb.py", line 100, in get_thread_info
    current_thread_id = result['current-thread-id']
TypeError: 'NoneType' object is not subscriptable

Btw: The dgb_corefile function seems to work like in the official doc example: espcoredump.py -p COM5 dbg_corefile C:\Users\ddomnik\Documents\esp\coredump\build\coredump.elf

[...]
Reading symbols from C:\Users\ddomnik\Documents\esp\coredump\build\coredump.elf...
[New process 1070545612]
[New process 1070547500]
[New process 1070549388]
[New process 1070535060]
[New process 1070540884]
[New process 1070536436]
#0  0x40375899 in panic_abort (details=0x3fcf37fb "assert failed: app_main main.c:46 (0)")
    at C:/Espressif/frameworks/esp-idf-master/components/esp_system/panic.c:409
409         *((volatile int *) 0) = 0; // NOLINT(clang-analyzer-core.NullDereference) should be an invalid operation on targets
[Current thread is 1 (process 1070545612)]
(gdb) p global_var
$1 = 25 '\031'
(gdb)
borjanbozhinovski commented 8 months ago

Is there any update regarding this issue? I am still getting the same behavior as explained by @ddomnik, using following commands:

erhankur commented 2 months ago

@borjanbozhinovski Did you try to transfer the coredump data with the lower speeds? e.g: 115200

borjanbozhinovski commented 2 months ago

@erhankur Actually, I do not remember if I tried with lower speed, as this is something that I was working on 6 mouths ago. Do you think that lower speed will fix the behavior?

erhankur commented 2 months ago

@borjanbozhinovski I couldn't reproduce this yet. We have several users who reported a similar issue on Windows. Not sure lower speed will fix it but I thought It was worth trying. From what I understand, coredump data is not corrupted but we can't transfer it for some reason. Anyway, if you see an error again, please let us know.