riscvarchive / riscv-binutils-gdb

RISC-V backports for binutils-gdb. Development is done upstream at the FSF.
GNU General Public License v2.0
149 stars 233 forks source link

gdb/infrun.c:5300: internal-error #230

Open luyahan opened 4 years ago

luyahan commented 4 years ago

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.
kito-cheng commented 4 years ago

Do you mind give more context about how to reproduce that?

luyahan commented 4 years ago

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)
jim-wilson commented 4 years ago

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.

Shai-Aviv commented 3 years ago

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.