Skip to content
This repository has been archived by the owner on Aug 17, 2022. It is now read-only.

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

Open
luyahan opened this issue Aug 24, 2020 · 4 comments
Open

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

luyahan opened this issue Aug 24, 2020 · 4 comments

Comments

@luyahan
Copy link

luyahan commented Aug 24, 2020

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
Copy link
Collaborator

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

@luyahan
Copy link
Author

luyahan commented Aug 24, 2020

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
Copy link
Collaborator

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
Copy link

Shai-Aviv commented Apr 5, 2021

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants