Running gdb 8.0 on a RHEL6 VM: $ uname -a Linux hostname 2.6.32-504.38.1.el6.x86_64 #1 SMP Sun Oct 4 13:43:08 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux Produced the following output: ../../gdb/regcache.c:1087: internal-error: void regcache_raw_supply(regcache, int, const void): Assertion `regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) [answered Y; input not from terminal] Dumping the stack from the core file produces: (gdb) where #0 0x0000003fc3e32625 in raise () from /lib64/libc.so.6 #1 0x0000003fc3e33e05 in abort () from /lib64/libc.so.6 #2 0x000000000078267e in dump_core() () #3 0x0000000000782af7 in internal_vproblem(internal_problem*, char const*, int, char const*, __va_list_tag*) () #4 0x0000000000782b6f in internal_verror(char const*, int, char const*, __va_list_tag*) () #5 0x0000000000641e26 in internal_error(char const*, int, char const*, ...) () #6 0x0000000000712883 in regcache_raw_supply(regcache*, int, void const*) () #7 0x000000000046c6f8 in amd64_linux_fetch_inferior_registers(target_ops*, regcache*, int) () #8 0x0000000000754802 in delegate_fetch_registers(target_ops*, regcache*, int) () #9 0x0000000000768aa8 in target_fetch_registers(regcache*, int) () #10 0x0000000000479622 in ps_lgetregs () #11 0x00007f1f6252fb58 in __td_ta_lookup_th_unique () from /lib64/libthread_db.so.1 #12 0x00007f1f6252fd8a in td_ta_map_lwp2thr () from /lib64/libthread_db.so.1 #13 0x0000000000479c7c in thread_from_lwp(ptid_t) () #14 0x000000000047a4b1 in try_thread_db_load_1(thread_db_info*) () #15 0x000000000047a7df in try_thread_db_load(char const*, int) () #16 0x000000000047aab1 in try_thread_db_load_from_sdir() () #17 0x000000000047acbf in thread_db_load_search() () #18 0x000000000047ae41 in thread_db_load() () #19 0x000000000047af72 in check_for_thread_db() () #20 0x000000000047b007 in thread_db_new_objfile(objfile*) () #21 0x00000000006e2434 in observer_new_objfile_notification_stub(void const*, void const*) () #22 0x00000000006e1802 in generic_observer_notify(observer_list*, void const*) () #23 0x00000000006e24c7 in observer_notify_new_objfile(objfile*) () #24 0x000000000073c478 in symbol_file_add_with_addrs(bfd*, char const*, enum_flags<symfile_add_flag>, section_addr_info*, enum_flags<objfile_flag>, objfile*) () #25 0x000000000073c61e in symbol_file_add_from_bfd(bfd*, char const*, enum_flags<symfile_add_flag>, section_addr_info*, enum_flags<objfile_flag>, objfile*) () #26 0x0000000000721c66 in solib_read_symbols(so_list*, enum_flags<symfile_add_flag>) () #27 0x0000000000722490 in solib_add(char const*, int, int) () #28 0x0000000000458a77 in enable_break(svr4_info*, int) () #29 0x000000000045a655 in svr4_solib_create_inferior_hook(int) () #30 0x0000000000722e70 in solib_create_inferior_hook(int) () #31 0x000000000068e11e in post_create_inferior(target_ops*, int) () #32 0x00000000006920a0 in setup_inferior(int) () #33 0x00000000006920e6 in attach_post_wait(char const*, int, attach_post_wait_mode) () #34 0x00000000006922af in attach_command_continuation(void*, int) () #35 0x00000000005d4556 in do_my_continuations_1(continuation**, int) () #36 0x00000000005d45e1 in do_my_continuations(continuation**, int) () #37 0x00000000005d46d9 in do_all_inferior_continuations(int) () #38 0x000000000068b4a5 in inferior_event_handler(inferior_event_type, void*) () #39 0x000000000069be0e in fetch_inferior_event(void*) () #40 0x000000000068b43f in inferior_event_handler(inferior_event_type, void*) () #41 0x00000000006a653e in infrun_async_inferior_event_handler(void*) () #42 0x000000000064c4e3 in check_async_event_handlers() () #43 0x000000000064ae53 in gdb_do_one_event() () #44 0x000000000064aefa in start_event_loop() () #45 0x00000000006c1cbb in captured_command_loop(void*) () #46 0x000000000064e9ef in catch_errors(int (*)(void*), void*, char const*, return_mask) () #47 0x00000000006c30d0 in captured_main(void*) () #48 0x00000000006c30f9 in gdb_main(captured_main_args*) () #49 0x000000000040a817 in main () (gdb) up #6 0x0000000000712883 in regcache_raw_supply(regcache*, int, void const*) () (gdb) info registers rax 0x0 0 rbx 0x2a648 173640 rcx 0xffffffffffffffff -1 rdx 0x6 6 rsi 0x2a8ed 174317 rdi 0x2a8ed 174317 rbp 0x7ffe49d38630 0x7ffe49d38630 rsp 0x7ffe49d38600 0x7ffe49d38600 r8 0xffffffff 4294967295 r9 0x7f1f63a70700 139772792604416 r10 0x8 8 r11 0x206 518 r12 0x7ffe49d39720 140730137024288 r13 0x7ffe49d39500 140730137023744 r14 0x0 0 r15 0x0 0 rip 0x712883 0x712883 <regcache_raw_supply(regcache*, int, void const*)+135> eflags 0x206 [ PF IF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0
The bug appears to be here: #ifndef HAVE_STRUCT_USER_REGS_STRUCT_FS_BASE { /* PTRACE_ARCH_PRCTL is obsolete since 2.6.25, where the fs_base and gs_base fields of user_regs_struct can be used directly. */ unsigned long base; if (regnum == -1 || regnum == AMD64_FSBASE_REGNUM) { if (ptrace (PTRACE_ARCH_PRCTL, tid, &base, ARCH_GET_FS) < 0) perror_with_name (_("Couldn't get segment register fs_base")); regcache_raw_supply (regcache, AMD64_FSBASE_REGNUM, &base); } if (regnum == -1 || regnum == AMD64_GSBASE_REGNUM) { if (ptrace (PTRACE_ARCH_PRCTL, tid, &base, ARCH_GET_GS) < 0) perror_with_name (_("Couldn't get segment register gs_base")); regcache_raw_supply (regcache, AMD64_GSBASE_REGNUM, &base); } } #endif This code must be getting hit because the binary was built on a RHEL5 system with 2.6.18 kernel. The reg cache does not allow the pseudo registers into the cache: /* Construct a strictly RAW register cache. Don't allow pseudo's into the register cache. */ descr->nr_raw_registers = gdbarch_num_regs (gdbarch); descr->sizeof_raw_register_status = gdbarch_num_regs (gdbarch);
This appears to be the commit: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=2735833d5fb220983d09770087b573fed5bf93cd
It should be noted that modifying `configure` to force on `HAVE_STRUCT_USER_REGS_STRUCT_FS_BASE` and `HAVE_STRUCT_USER_REGS_STRUCT_GS_BASE` fixes this issue. For some reason the `configure` tests for `fs_base` and `gs_base` fail even though `sys/user.h` on RHEL5 has the fields defined in `user_regs_struct`.
The master branch has been updated by Pedro Alves <palves@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f517c1805ac50c64c2dbb086c16b3bcf33b15a89 commit f517c1805ac50c64c2dbb086c16b3bcf33b15a89 Author: Eldar Abusalimov <eldar.abusalimov@jetbrains.com> Date: Mon Jan 15 16:57:42 2018 +0300 configure: Fix test for fs_base/gs_base in <sys/user.h> Make <sys/types.h> be included prior to including <sys/user.h>. glibc versions older than 2.14 use __uintNN_t types within certain structures defined in <sys/user.h> probably assuming these types are defined prior to including the header. This results in the following `configure` feature test compilation error that makes it think that `struct user_regs_struct` doesn't have `fs_base`/`gs_base` fields, althouh it does. configure:13617: checking for struct user_regs_struct.fs_base configure:13617: gcc -c -g -O2 -I/linux/include conftest.c >&5 In file included from conftest.c:158:0: /usr/include/sys/user.h:32:3: error: unknown type name '__uint16_t' __uint16_t cwd; ^ /usr/include/sys/user.h:33:3: error: unknown type name '__uint16_t' __uint16_t swd; ^ /usr/include/sys/user.h:34:3: error: unknown type name '__uint16_t' __uint16_t ftw; ^ /usr/include/sys/user.h:35:3: error: unknown type name '__uint16_t' __uint16_t fop; ^ /usr/include/sys/user.h:36:3: error: unknown type name '__uint64_t' __uint64_t rip; ^ /usr/include/sys/user.h:37:3: error: unknown type name '__uint64_t' __uint64_t rdp; ^ /usr/include/sys/user.h:38:3: error: unknown type name '__uint32_t' __uint32_t mxcsr; ^ /usr/include/sys/user.h:39:3: error: unknown type name '__uint32_t' __uint32_t mxcr_mask; ^ /usr/include/sys/user.h:40:3: error: unknown type name '__uint32_t' __uint32_t st_space[32]; /* 8*16 bytes for each FP-reg = 128 bytes */ ^ /usr/include/sys/user.h:41:3: error: unknown type name '__uint32_t' __uint32_t xmm_space[64]; /* 16*16 bytes for each XMM-reg = 256 bytes */ ^ /usr/include/sys/user.h:42:3: error: unknown type name '__uint32_t' __uint32_t padding[24]; ^ configure:13617: $? = 1 configure: failed program was: | /* confdefs.h */ ... | /* end confdefs.h. */ | #include <sys/user.h> | | int | main () | { | static struct user_regs_struct ac_aggr; | if (ac_aggr.fs_base) | return 0; | ; | return 0; | } Recent glibc versions don't use typedef'ed int types in <sys/user.h>, thus allowing it to be included as is (glibc commit d79a9c949c84e7f0ba33e87447c47af833e9f11a). However there're still some distros alive that use older glibc, for instance, RHEL/CentOS 6 package glibc 2.12. Also affects PR gdb/21559: ../../gdb/regcache.c:1087: internal-error: void regcache_raw_supply(regcache, int, const void): Assertion `regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed. As noted by Andrew Paprocki, who submitted the PR (https://sourceware.org/bugzilla/show_bug.cgi?id=21559#c3): > It should be noted that modifying `configure` to force on > `HAVE_STRUCT_USER_REGS_STRUCT_FS_BASE` and > `HAVE_STRUCT_USER_REGS_STRUCT_GS_BASE` fixes this issue. For some > reason the `configure` tests for `fs_base` and `gs_base` fail > even though `sys/user.h` on RHEL5 has the fields defined in > `user_regs_struct`. Note that this patch does NOT fix the root cause of PR gdb/21559, although now that `configure` properly detects the presence of the fields and sets HAVE_XXX accordingly, the execution takes another path, which doesn't lead to the assertion failure in question. gdb/ChangeLog: 2018-01-17 Eldar Abusalimov <eldar.abusalimov@jetbrains.com> PR gdb/21559 * configure.ac: Include <sys/types.h> prior to <sys/user.h> when checking for fs_base/gs_base fields in struct user_regs_struct. * configure: Regenerate. gdb/gdbserver/ChangeLog: 2018-01-17 Eldar Abusalimov <eldar.abusalimov@jetbrains.com> PR gdb/21559 * configure.ac: Include <sys/types.h> prior to <sys/user.h> when checking for fs_base/gs_base fields in struct user_regs_struct. * configure: Regenerate.
The gdb-8.1-branch branch has been updated by Pedro Alves <palves@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6949085e3eaef536b2c76252452ec3e63e9f112c commit 6949085e3eaef536b2c76252452ec3e63e9f112c Author: Eldar Abusalimov <eldar.abusalimov@jetbrains.com> Date: Wed Jan 17 13:13:15 2018 +0000 configure: Fix test for fs_base/gs_base in <sys/user.h> Make <sys/types.h> be included prior to including <sys/user.h>. glibc versions older than 2.14 use __uintNN_t types within certain structures defined in <sys/user.h> probably assuming these types are defined prior to including the header. This results in the following `configure` feature test compilation error that makes it think that `struct user_regs_struct` doesn't have `fs_base`/`gs_base` fields, althouh it does. configure:13617: checking for struct user_regs_struct.fs_base configure:13617: gcc -c -g -O2 -I/linux/include conftest.c >&5 In file included from conftest.c:158:0: /usr/include/sys/user.h:32:3: error: unknown type name '__uint16_t' __uint16_t cwd; ^ /usr/include/sys/user.h:33:3: error: unknown type name '__uint16_t' __uint16_t swd; ^ /usr/include/sys/user.h:34:3: error: unknown type name '__uint16_t' __uint16_t ftw; ^ /usr/include/sys/user.h:35:3: error: unknown type name '__uint16_t' __uint16_t fop; ^ /usr/include/sys/user.h:36:3: error: unknown type name '__uint64_t' __uint64_t rip; ^ /usr/include/sys/user.h:37:3: error: unknown type name '__uint64_t' __uint64_t rdp; ^ /usr/include/sys/user.h:38:3: error: unknown type name '__uint32_t' __uint32_t mxcsr; ^ /usr/include/sys/user.h:39:3: error: unknown type name '__uint32_t' __uint32_t mxcr_mask; ^ /usr/include/sys/user.h:40:3: error: unknown type name '__uint32_t' __uint32_t st_space[32]; /* 8*16 bytes for each FP-reg = 128 bytes */ ^ /usr/include/sys/user.h:41:3: error: unknown type name '__uint32_t' __uint32_t xmm_space[64]; /* 16*16 bytes for each XMM-reg = 256 bytes */ ^ /usr/include/sys/user.h:42:3: error: unknown type name '__uint32_t' __uint32_t padding[24]; ^ configure:13617: $? = 1 configure: failed program was: | /* confdefs.h */ ... | /* end confdefs.h. */ | #include <sys/user.h> | | int | main () | { | static struct user_regs_struct ac_aggr; | if (ac_aggr.fs_base) | return 0; | ; | return 0; | } Recent glibc versions don't use typedef'ed int types in <sys/user.h>, thus allowing it to be included as is (glibc commit d79a9c949c84e7f0ba33e87447c47af833e9f11a). However there're still some distros alive that use older glibc, for instance, RHEL/CentOS 6 package glibc 2.12. Also affects PR gdb/21559: ../../gdb/regcache.c:1087: internal-error: void regcache_raw_supply(regcache, int, const void): Assertion `regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed. As noted by Andrew Paprocki, who submitted the PR (https://sourceware.org/bugzilla/show_bug.cgi?id=21559#c3): > It should be noted that modifying `configure` to force on > `HAVE_STRUCT_USER_REGS_STRUCT_FS_BASE` and > `HAVE_STRUCT_USER_REGS_STRUCT_GS_BASE` fixes this issue. For some > reason the `configure` tests for `fs_base` and `gs_base` fail > even though `sys/user.h` on RHEL5 has the fields defined in > `user_regs_struct`. Note that this patch does NOT fix the root cause of PR gdb/21559, although now that `configure` properly detects the presence of the fields and sets HAVE_XXX accordingly, the execution takes another path, which doesn't lead to the assertion failure in question. gdb/ChangeLog: 2018-01-17 Eldar Abusalimov <eldar.abusalimov@jetbrains.com> PR gdb/21559 * configure.ac: Include <sys/types.h> prior to <sys/user.h> when checking for fs_base/gs_base fields in struct user_regs_struct. * configure: Regenerate. gdb/gdbserver/ChangeLog: 2018-01-17 Eldar Abusalimov <eldar.abusalimov@jetbrains.com> PR gdb/21559 * configure.ac: Include <sys/types.h> prior to <sys/user.h> when checking for fs_base/gs_base fields in struct user_regs_struct. * configure: Regenerate.
Fix merged. Thanks.
(In reply to Pedro Alves from comment #6) > Fix merged. Thanks. Pedro, I'm not sure we should actually close this ticket. The merged patch makes the issue go away indeed, however it doesn't fix the root cause of the assertion failure, I'm afraid. > Note that this patch does NOT fix the root cause of PR gdb/21559, > although now that `configure` properly detects the presence of the > fields and sets HAVE_XXX accordingly, the execution takes another > path, which doesn't lead to the assertion failure in question.