Open luyahan opened 4 years ago
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.
error log:
Gdb info: