GDB: Assertion while unwinding stack
rojer opened this issue · 0 comments
rojer commented
When unwinding stack, GDB fails with internal assertion if next frame pointer happens to be 0.
In this case, this is a legitimate value - it's the end of the stack of this particular task and GDB should stop unwinding.
Instead, this is what happens:
[rojer@nba ~/go/src/cesanta.com/fw/platforms/esp8266 mos1]$ make debug_coredump CONSOLE_LOG=/tmp/console.log
Waiting for gdb on 1234
GNU gdb (crosstool-NG crosstool-ng-1.22.0-55-gecfc19a) 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=x86_64-build_pc-linux-gnu --target=xtensa-lx106-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/mongoose-os.elf...done.
Remote debugging using 127.0.0.1:1234
Found core at 1202 - 177340
Mapping DRAM: 98304 @ 0x3ffe8000
Mapping IRAM: 32768 @ 0x40100000
Mapping IROM: 460784 @ 0x40211000
Mapping /mongoose-os/common/platforms/esp8266/rom/rom.bin at 0x40000000
Loaded core dump from last snippet in /console.log
>> qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+
>> Hg0
>> qTStatus
>> ?
>> qfThreadInfo
>> Hc-1
>> qC
>> qAttached
>> qOffsets
>> g
>> qfThreadInfo
>> m4023f1d1,4
<< 39 02 01 e7
>> m4023f0e8,20
<< 12 c1 e0 09 71 c9 61 d9 51 29 01 45 59 02 85 be 08 56 52 0e 0c 13 21 ec ff 32 42 00 c1 dd ff 28
>> m3fff5d2c,4
<< 47 f2 23 40
>> m4023f247,4
<< cd 02 0c 13
>> m4023f218,20
<< 12 c1 e0 09 71 c9 61 d9 51 e9 41 45 07 d4 3d 02 21 f8 ff 01 85 47 c0 00 00 2c 02 0c 83 0c 04 05
>> m3fff5d4c,4
<< 00 00 00 00
0x4023f1d1 in esp_mgos_init2 (
/opt/Espressif/esp-open-sdk/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) n
here >> denote the GDB commands received by our core dump server and << are responses to the m commands. Fetch of 0x3fff5d4c is GDB making the next step up, the trace but there is nothing there (legitimately) and it crashes and burns.
If i patch up CD server to return non-zero, unwind finishes correctly:
Loaded core dump from last snippet in /console.log
>> qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+
>> Hg0
>> qTStatus
>> ?
>> qfThreadInfo
>> Hc-1
>> qC
>> qAttached
>> qOffsets
>> g
>> qfThreadInfo
>> m4023f1d1,4
<< 39 02 01 e7
>> m4023f0e8,20
<< 12 c1 e0 09 71 c9 61 d9 51 29 01 45 59 02 85 be 08 56 52 0e 0c 13 21 ec ff 32 42 00 c1 dd ff 28
>> m3fff5d2c,4
<< 47 f2 23 40
>> m4023f247,4
<< cd 02 0c 13
>> m4023f218,20
<< 12 c1 e0 09 71 c9 61 d9 51 e9 41 45 07 d4 3d 02 21 f8 ff 01 85 47 c0 00 00 2c 02 0c 83 0c 04 05
>> m3fff5d4c,4
<< 01 00 00 00
>> m3fff5d10,4
<< 84 64 ff 3f
0x4023f1d1 in esp_mgos_init2 (bcfg=bcfg@entry=0x3fff6484)
at /mongoose-os/fw/platforms/esp8266/src/esp_main.c:127
127 *((int *) 0x123) = 1;
>> qSymbol::
add symbol table from file "/mongoose-os/common/platforms/esp8266/rom/rom.elf" at
.text_addr = 0x40000000
Reading symbols from /mongoose-os/common/platforms/esp8266/rom/rom.elf...(no debugging symbols found)...done.
>> qSymbol::
>> m4023f1d1,4
<< 39 02 01 e7
>> m4023f0e8,20
<< 12 c1 e0 09 71 c9 61 d9 51 29 01 45 59 02 85 be 08 56 52 0e 0c 13 21 ec ff 32 42 00 c1 dd ff 28
>> m3fff5d2c,4
<< 47 f2 23 40
(gdb) bt
>> m4023f247,4
<< cd 02 0c 13
>> m4023f218,20
<< 12 c1 e0 09 71 c9 61 d9 51 e9 41 45 07 d4 3d 02 21 f8 ff 01 85 47 c0 00 00 2c 02 0c 83 0c 04 05
>> m3fff5d4c,4
<< 01 00 00 00
>> m3fff5d10,4
<< 84 64 ff 3f
#0 0x4023f1d1 in esp_mgos_init2 (bcfg=bcfg@entry=0x3fff6484)
at /mongoose-os/fw/platforms/esp8266/src/esp_main.c:127
#1 0x4023f247 in esp_mgos_init ()
at /mongoose-os/fw/platforms/esp8266/src/esp_main.c:158
>> m1,4
Unmapped addr 0x1
<< 01 00 00 00
>> m3fff5d4c,4
<< 01 00 00 00
#2 mgos_task (arg=<optimized out>)
at /mongoose-os/fw/platforms/esp8266/src/esp_main.c:201
#3 0x00000001 in ?? ()
>> m1,4
Unmapped addr 0x1
<< 01 00 00 00
>> m3fff5d4c,4
<< 01 00 00 00
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
here i told CD to return 0x1 instead and GDB was able to proceed (although it tried to fetch 0x1 and that failed). backtrace is correct: mgos_task is the main function of the task and there's nothing beyond it.