Created attachment 8143 [details] Backtrace of crashed gdb gdb is crashing at startup on a big, complex executable I'm trying to debug. As the attached backtrace shows, something's going haywire in dwarf2_add_member_fn().
Created attachment 8144 [details] Valgrind run of segfaulting gdb Output from "valgrind --track-origins=yes" run on gdb. The relevant part is the stanza right before the SIGSEGV, in which Valgrind complains that gdb is attempting an "Invalid read of size 8" because "Address 0x10 is not stack'd, malloc'd or (recently) free'd".
Created attachment 8145 [details] Problematic executable Attached the x86-64 executable that's crashing gdb. It's a build of NuT (https://github.com/losalamos/NuT) instrumented with Byfl (https://github.com/losalamos/Byfl). I built the code with g++ v4.9 on Ubuntu 14.10 (Utopic Unicorn), and here are the program's dependencies: $ ldd ./export/opt-3-export_x86_scalar/bin/bh-3 linux-vdso.so.1 => (0x00007fffbdbfc000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fee2364c000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fee2333c000) libatomic.so.1 => /usr/lib/x86_64-linux-gnu/libatomic.so.1 (0x00007fee23134000) libbfd-2.24.90-system.20141014.so => /usr/lib/libbfd-2.24.90-system.20141014.so (0x00007fee22dfc000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fee22be4000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fee2281f000) /lib64/ld-linux-x86-64.so.2 (0x00007fee2397f000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fee22601000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fee223e7000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fee221e3000)
Proposed patch submitted: https://sourceware.org/ml/gdb-patches/2015-03/msg00047.html
(In reply to Keith Seitz from comment #3) > Proposed patch submitted: > https://sourceware.org/ml/gdb-patches/2015-03/msg00047.html The segfault seems to have gone away when I applied that patch -- thanks!
The master branch has been updated by Keith Seitz <kseitz@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7e993ebf2343a5b39d6d1df29fdebc2818064ae5 commit 7e993ebf2343a5b39d6d1df29fdebc2818064ae5 Author: Keith Seitz <keiths@redhat.com> Date: Fri Feb 27 09:55:07 2015 -0800 PR gdb/18021 - defend against "static virtual" methods This bug appears to be caused by bad debuginfo. The method causing the sefault in the reporter's test case is marked both static and virtual. This patch simply safegaurds against this case in dwarf2_add_member_fn, where the code assumes that there is a `this' pointer when a virtual method is seen (more specifically, when DW_AT_vtable_elem is seen). It previously dereferenced the first formal parameter (`this' pointer), which in this case doesn't exist. GDB consequently segfaulted dereferencing a NULL pointer. gdb/ChangeLog PR gdb/18021 * dwarf2read.c (dwarf2_add_member_fn): Issue a complaint if we find a static method with DW_AT_vtable_elem_location. gdb/testsuite/ChangeLog PR gdb/18021 * gdb.dwarf2/staticvirtual.exp: New test.
Patch committed. If you have any further issues, please let us/me know.