riscv-binutils-gdb
riscv-binutils-gdb copied to clipboard
gdb/infrun.c:5300: internal-error
error log:
../../gdb/infrun.c:5300: internal-error: int finish_step_over(execution_control_state*): Assertion `ecs->event_thread->control.trap_expected' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Gdb info:
GNU gdb (GDB) Fedora 9.0.50.20191119-2.0.riscv64.fc32
Copyright (C) 2019 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.
Do you mind give more context about how to reproduce that?
Do you mind give more context about how to reproduce that?
I am debugging program v8 on hifive unleashed. When running program without gdb, it recived a signal: Received signal 11 SEGV_MAPERR 000000001d30
. When i run it with gdb, it sometimes occur this internal-error:
../../gdb/infrun.c:5300: internal-error: int finish_step_over(execution_control_state*): Assertion `ecs->event_thread->control.trap_expected' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
Missing separate debuginfos, use: dnf debuginfo-installPlease answer y or n.
../../gdb/infrun.c:5300: internal-error: int finish_step_over(execution_control_state*): Assertion `ecs->event_thread->control.trap_expected' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y
This is a bug, please report it. For instructions, see:
<http://www.gnu.org/software/gdb/bugs/>.
../../gdb/infrun.c:5300: internal-error: int finish_step_over(execution_control_state*): Assertion `ecs->event_thread->control.trap_expected' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) y
,but sometimes it normally remind me SIGSEGV:
Thread 3 "V8 DefaultWorke" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x3ff75ce1c0 (LWP 1147500)]
0x0000000000001d30 in ?? ()
core dump info:
yahan@fedora-riscv-sifive:~ $ coredumpctl gdb
PID: 1147441 (gdb)
UID: 1002 (yahan)
GID: 1002 (yahan)
Signal: 6 (ABRT)
Timestamp: Mon 2020-08-24 00:44:52 EDT (3min 47s ago)
Command Line: gdb ./d8
Executable: /usr/libexec/gdb
Control Group: /user.slice/user-1002.slice/session-180.scope
Unit: session-180.scope
Slice: user-1002.slice
Session: 180
Owner UID: 1002 (yahan)
Boot ID: 0ff85bc11c41467e8f0cdd6f9c407247
Machine ID: c59960756c71ae4680a9024e974e6049
Hostname: fedora-riscv-sifive
Storage: /var/lib/systemd/coredump/core.gdb.1002.0ff85bc11c41467e8f0cdd6f9c407247.1147441.1598244292000000000000.lz4
Message: Process 1147441 (gdb) of user 1002 dumped core.
Stack trace of thread 1147441:
#0 0x0000003fbb430778 raise (libc.so.6 + 0x32778)
#1 0x0000003fbb420fee abort (libc.so.6 + 0x22fee)
#2 0x0000002ad1e013ae _Z9dump_corev (gdb + 0x4203ae)
#3 0x0000002ad1e04f42 _ZL17internal_vproblemP16internal_problemPKciS2_Pv (gdb + 0x423f42)
#4 0x0000002ad1e050c6 _Z15internal_verrorPKciS0_Pv (gdb + 0x4240c6)
#5 0x0000002ad1c30db4 _Z14internal_errorPKciS0_z (gdb + 0x24fdb4)
#6 0x0000002ad1c5a580 _ZL18handle_signal_stopP23execution_control_state (gdb + 0x279580)
#7 0x0000002ad1c5ad32 _ZL21handle_inferior_eventP23execution_control_state (gdb + 0x279d32)
#8 0x0000002ad1c5b9e8 _Z20fetch_inferior_eventPv (gdb + 0x27a9e8)
#9 0x0000002ad1c0d88c _ZL18gdb_wait_for_eventi (gdb + 0x22c88c)
#10 0x0000002ad1c0dc2c _Z16gdb_do_one_eventv.part.0 (gdb + 0x22cc2c)
#11 0x0000002ad1c0dd2e _Z16start_event_loopv (gdb + 0x22cd2e)
#12 0x0000002ad1c86874 _ZL21captured_command_loopv (gdb + 0x2a5874)
#13 0x0000002ad1c8834c _Z8gdb_mainP18captured_main_args (gdb + 0x2a734c)
#14 0x0000002ad1b0351a main (gdb + 0x12251a)
#15 0x0000003fbb421204 __libc_start_main (libc.so.6 + 0x23204)
#16 0x0000002ad1b0cfb8 _start (gdb + 0x12bfb8)
We don't have a dedicated gdb developer. I would suggest filing a bug report upstream with FSF GDB. And maybe try using more recent FSF GDB sources to see if that helps.
I'm hitting the same issue on Spike with 2 threads, probably FSF bug 26819 which is (at least partially) resolved by commit 64d38fd. Are there any plans to backport it?
Edit: I built the FSF GDB version and it seems to debug Spike with 2 threads just fine. Since RISC-V support is already upstream, I assume backporting is no longer necessary.