search

espressif / esp-idf

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

/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/gdb/gdb/thread.c:93: internal-error: thread_info* inferior_thread(): Assertion `tp' failed. (IDFGH-3361) #5337

Open aep opened 4 years ago

aep commented 4 years ago

Problem Description

idf.py monitor with gdb stubs doesnt work

//Detailed problem description goes here.


***ERROR*** A stack overflow in task carrier has been detected.

Backtrace:0x4008eb63:0x3ffe0340 0x4008e885:0x3ffe0360 0x4009b5a9:0x3ffe0380 0x4009cd0a:0x3ffe0400 0x4009b69c:0x3ffe0420 0x4009b652:0x00000000 |<-CORRUPTED
0x4008eb63: panic_abort at /opt/toolchains/esp32/idf/components/esp_system/panic.c:330

0x4008e885: esp_system_abort at /opt/toolchains/esp32/idf/components/esp_system/system_api.c:97

0x4009b5a9: vApplicationStackOverflowHook at /opt/toolchains/esp32/idf/components/freertos/xtensa/port.c:436

0x4009cd0a: vTaskSwitchContext at /opt/toolchains/esp32/idf/components/freertos/tasks.c:2769

0x4009b69c: _frxt_dispatch at /opt/toolchains/esp32/idf/components/freertos/xtensa/portasm.S:431

0x4009b652: _frxt_int_exit at /opt/toolchains/esp32/idf/components/freertos/xtensa/portasm.S:231

ELF file SHA256: 6a0adf99108b697c

Entering gdb stub now.
$T0b#e6GNU gdb (crosstool-NG esp-2020r1) 8.1.0.20180627-git
Copyright (C) 2018 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=x86_64-build_pc-linux-gnu --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 /home/aep/proj/corona/esp/counter/build/crs19.elf...done.
Remote debugging using /dev/ttyUSB0
/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/gdb/gdb/thread.c:93: internal-error: thread_info* inferior_thread(): Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n
igrr commented 4 years ago

Hi @aep, do you see this behavior on every crash, or only when the stack overflow is detected? I made a trivial test application which overflows the stack, but couldn't get the same behavior. Do you think you could trim your app down to something that reproduces the issue?

aep commented 4 years ago

i'm having difficulties reproducing this as well. the root cause was a function with very large stack values calling itself.

this code wont even trigger stack smashing protection, it just resets due to watchdog

void large_stack()
{
    char something[10000];
    memset(something, 0xff, 10000);
    large_stack();
}

void app_main(void)
{
    large_stack();
}
igrr commented 4 years ago

Could you try adding CONFIG_FREERTOS_WATCHPOINT_END_OF_STACK=y to your sdkconfig?

I think this issue can not be detected with stack smashing protection, because from the C compiler perspective stack smashing is not happening — the memset stays within the boundaries of the function's stack frame. The issue is that the stack frame overflows the space available on the stack. The above mentioned option is not a guaranteed way to catch such stack overflow (it won't help if you memset only the last 1k of the array), but it still increases the chances of detecting this early.

aep commented 4 years ago

yeah this is with

aep commented 4 years ago

any idea how i could intentionally trigger a context switch? the problematic app had 10 tasks, so maybe its not reproducible because its just 1 task