[Bug gdb/17968] New: [ppc64] SEGV in ppc64_elf_get_synthetic_symtab reading a separate debug file

[Bug gdb/17968] New: [ppc64] SEGV in ppc64_elf_get_synthetic_symtab reading a separate debug file

[msebor at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17968

            Bug ID: 17968
           Summary: [ppc64] SEGV in ppc64_elf_get_synthetic_symtab reading
                    a separate debug file
           Product: gdb
           Version: 7.8
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: msebor at redhat dot com

GDB 7.8 (and 7.7 and 7.6 before it) crashes while reading the .debug file for a
large number (over 380 out of about 1800 installed on my machine) of kernel
modules on RHEL 7.  The stack trace is below.  The crash only happens when both
the module and the debug file are read in a single operation and not in
separate steps (e.g., by invoking the file command first, and then symbol-file
next).

$ /usr/bin/gdb -q --args /build/gdb-7.8.2.bin/bin/gdb -q /lib/modules/$(uname
-r)/kernel/lib/cordic.ko
Reading symbols from /build/gdb-7.8.2.bin/bin/gdb...done.
(gdb) r
Starting program: /build/gdb-7.8.2.bin/bin/gdb -q
/lib/modules/3.10.0-227.el7.ppc64/kernel/lib/cordic.ko
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Detaching after fork from child process 55001.
Reading symbols from
/lib/modules/3.10.0-227.el7.ppc64/kernel/lib/cordic.ko...Reading symbols from
/usr/lib/debug/lib/modules/3.10.0-227.el7.ppc64/kernel/lib/cordic.ko.debug...
Program received signal SIGSEGV, Segmentation fault.
ppc64_elf_get_synthetic_symtab (abfd=<optimized out>, 
    static_count=<optimized out>, static_syms=<optimized out>, 
    dyn_count=<optimized out>, dyn_syms=<optimized out>, ret=0x3fffffffe120)
    at elf64-ppc.c:3259
3259          if (!sym_exists_at (syms, opdsymend, symcount,
Missing separate debuginfos, use: debuginfo-install expat-2.1.0-8.el7.ppc64
glibc-2.17-78.el7.ppc64 ncurses-libs-5.9-13.20130511.el7.ppc64
python-libs-2.7.5-16.el7.ppc64 xz-libs-5.1.2-9alpha.el7.ppc64
zlib-1.2.7-13.el7.ppc64
(gdb) l
3254    
3255          if (r->howto->type != R_PPC64_ADDR64)
3256            continue;
3257    
3258          sym = *r->sym_ptr_ptr;
3259          if (!sym_exists_at (syms, opdsymend, symcount,
3260                      sym->section->id, sym->value + r->addend))
3261            {
3262              ++count;
3263              size += sizeof (asymbol);
(gdb) p sym
$1 = (asymbol *) 0x0


The Valgrind output below shows a couple of invalid reads and some other
problems.  The overlapping memcpy errors are due to GCC bug 65042 and most
likely benign.

$ valgrind /build/gdb-7.8.2.bin/bin/gdb -q /lib/modules/$(uname
-r)/kernel/lib/cordic.ko
==55015== Memcheck, a memory error detector
==55015== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==55015== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==55015== Command: /build/gdb-7.8.2.bin/bin/gdb -q
/lib/modules/3.10.0-227.el7.ppc64/kernel/lib/cordic.ko
==55015== 
Reading symbols from
/lib/modules/3.10.0-227.el7.ppc64/kernel/lib/cordic.ko...==55015== Source and
destination overlap in memcpy(0xbe95a90, 0xbe95a90, 72)
==55015==    at 0x408C908: memcpy (in
/usr/lib64/valgrind/vgpreload_memcheck-ppc64be-linux.so)
==55015==    by 0x1029D853: compact_minimal_symbols (minsyms.c:1131)
==55015==    by 0x1029D853: install_minimal_symbols (minsyms.c:1256)
==55015==    by 0x10171B1B: elf_read_minimal_symbols (elfread.c:1220)
==55015==    by 0x10171B1B: elf_symfile_read (elfread.c:1264)
==55015==    by 0x1020F2A3: read_symbols (symfile.c:877)
==55015==    by 0x1020EC9B: syms_from_objfile_1 (symfile.c:1080)
==55015==    by 0x1020EC9B: syms_from_objfile (symfile.c:1096)
==55015==    by 0x1020EC9B: symbol_file_add_with_addrs (symfile.c:1193)
==55015==    by 0x1020F3F3: symbol_file_add_from_bfd (symfile.c:1282)
==55015==    by 0x1020F3F3: symbol_file_add (symfile.c:1297)
==55015==    by 0x1020F49B: symbol_file_add_main_1 (symfile.c:1322)
==55015==    by 0x10247F3B: catch_command_errors_const.constprop.5 (main.c:378)
==55015==    by 0x10248DDF: captured_main (main.c:1066)
==55015==    by 0x10242A5F: catch_errors (exceptions.c:506)
==55015==    by 0x10249507: gdb_main (main.c:1172)
==55015==    by 0x10084A87: main (gdb.c:33)
==55015== 
==55015== Source and destination overlap in memcpy(0xbe95f10, 0xbe95f10, 72)
==55015==    at 0x408C908: memcpy (in
/usr/lib64/valgrind/vgpreload_memcheck-ppc64be-linux.so)
==55015==    by 0x1029D87F: compact_minimal_symbols (minsyms.c:1133)
==55015==    by 0x1029D87F: install_minimal_symbols (minsyms.c:1256)
==55015==    by 0x10171B1B: elf_read_minimal_symbols (elfread.c:1220)
==55015==    by 0x10171B1B: elf_symfile_read (elfread.c:1264)
==55015==    by 0x1020F2A3: read_symbols (symfile.c:877)
==55015==    by 0x1020EC9B: syms_from_objfile_1 (symfile.c:1080)
==55015==    by 0x1020EC9B: syms_from_objfile (symfile.c:1096)
==55015==    by 0x1020EC9B: symbol_file_add_with_addrs (symfile.c:1193)
==55015==    by 0x1020F3F3: symbol_file_add_from_bfd (symfile.c:1282)
==55015==    by 0x1020F3F3: symbol_file_add (symfile.c:1297)
==55015==    by 0x1020F49B: symbol_file_add_main_1 (symfile.c:1322)
==55015==    by 0x10247F3B: catch_command_errors_const.constprop.5 (main.c:378)
==55015==    by 0x10248DDF: captured_main (main.c:1066)
==55015==    by 0x10242A5F: catch_errors (exceptions.c:506)
==55015==    by 0x10249507: gdb_main (main.c:1172)
==55015==    by 0x10084A87: main (gdb.c:33)
==55015== 
Reading symbols from
/usr/lib/debug/lib/modules/3.10.0-227.el7.ppc64/kernel/lib/cordic.ko.debug...==55015==
Invalid read of size 8
==55015==    at 0x105A9D54: ppc64_elf_get_synthetic_symtab (elf64-ppc.c:3258)
==55015==    by 0x10171A77: elf_read_minimal_symbols (elfread.c:1197)
==55015==    by 0x10171A77: elf_symfile_read (elfread.c:1264)
==55015==    by 0x1020F2A3: read_symbols (symfile.c:877)
==55015==    by 0x1020EC9B: syms_from_objfile_1 (symfile.c:1080)
==55015==    by 0x1020EC9B: syms_from_objfile (symfile.c:1096)
==55015==    by 0x1020EC9B: symbol_file_add_with_addrs (symfile.c:1193)
==55015==    by 0x1020F223: symbol_file_add_separate (symfile.c:1264)
==55015==    by 0x10171CEB: elf_symfile_read (elfread.c:1351)
==55015==    by 0x1020F2A3: read_symbols (symfile.c:877)
==55015==    by 0x1020EC9B: syms_from_objfile_1 (symfile.c:1080)
==55015==    by 0x1020EC9B: syms_from_objfile (symfile.c:1096)
==55015==    by 0x1020EC9B: symbol_file_add_with_addrs (symfile.c:1193)
==55015==    by 0x1020F3F3: symbol_file_add_from_bfd (symfile.c:1282)
==55015==    by 0x1020F3F3: symbol_file_add (symfile.c:1297)
==55015==    by 0x1020F49B: symbol_file_add_main_1 (symfile.c:1322)
==55015==    by 0x10247F3B: catch_command_errors_const.constprop.5 (main.c:378)
==55015==    by 0x10248DDF: captured_main (main.c:1066)
==55015==  Address 0xbe981e0 is 272 bytes inside a block of size 296 free'd
==55015==    at 0x40876CC: free (in
/usr/lib64/valgrind/vgpreload_memcheck-ppc64be-linux.so)
==55015==    by 0x10391A77: xfree (common-utils.c:108)
==55015==    by 0x101C74E7: do_my_cleanups (cleanups.c:155)
==55015==    by 0x10171B27: elf_read_minimal_symbols (elfread.c:1221)
==55015==    by 0x10171B27: elf_symfile_read (elfread.c:1264)
==55015==    by 0x1020F2A3: read_symbols (symfile.c:877)
==55015==    by 0x1020EC9B: syms_from_objfile_1 (symfile.c:1080)
==55015==    by 0x1020EC9B: syms_from_objfile (symfile.c:1096)
==55015==    by 0x1020EC9B: symbol_file_add_with_addrs (symfile.c:1193)
==55015==    by 0x1020F3F3: symbol_file_add_from_bfd (symfile.c:1282)
==55015==    by 0x1020F3F3: symbol_file_add (symfile.c:1297)
==55015==    by 0x1020F49B: symbol_file_add_main_1 (symfile.c:1322)
==55015==    by 0x10247F3B: catch_command_errors_const.constprop.5 (main.c:378)
==55015==    by 0x10248DDF: captured_main (main.c:1066)
==55015==    by 0x10242A5F: catch_errors (exceptions.c:506)
==55015==    by 0x10249507: gdb_main (main.c:1172)
==55015== 
==55015== Invalid read of size 8
==55015==    at 0x105A9DB4: ppc64_elf_get_synthetic_symtab (elf64-ppc.c:3294)
==55015==    by 0x10171A77: elf_read_minimal_symbols (elfread.c:1197)
==55015==    by 0x10171A77: elf_symfile_read (elfread.c:1264)
==55015==    by 0x1020F2A3: read_symbols (symfile.c:877)
==55015==    by 0x1020EC9B: syms_from_objfile_1 (symfile.c:1080)
==55015==    by 0x1020EC9B: syms_from_objfile (symfile.c:1096)
==55015==    by 0x1020EC9B: symbol_file_add_with_addrs (symfile.c:1193)
==55015==    by 0x1020F223: symbol_file_add_separate (symfile.c:1264)
==55015==    by 0x10171CEB: elf_symfile_read (elfread.c:1351)
==55015==    by 0x1020F2A3: read_symbols (symfile.c:877)
==55015==    by 0x1020EC9B: syms_from_objfile_1 (symfile.c:1080)
==55015==    by 0x1020EC9B: syms_from_objfile (symfile.c:1096)
==55015==    by 0x1020EC9B: symbol_file_add_with_addrs (symfile.c:1193)
==55015==    by 0x1020F3F3: symbol_file_add_from_bfd (symfile.c:1282)
==55015==    by 0x1020F3F3: symbol_file_add (symfile.c:1297)
==55015==    by 0x1020F49B: symbol_file_add_main_1 (symfile.c:1322)
==55015==    by 0x10247F3B: catch_command_errors_const.constprop.5 (main.c:378)
==55015==    by 0x10248DDF: captured_main (main.c:1066)
==55015==  Address 0xbe981e0 is 272 bytes inside a block of size 296 free'd
==55015==    at 0x40876CC: free (in
/usr/lib64/valgrind/vgpreload_memcheck-ppc64be-linux.so)
==55015==    by 0x10391A77: xfree (common-utils.c:108)
==55015==    by 0x101C74E7: do_my_cleanups (cleanups.c:155)
==55015==    by 0x10171B27: elf_read_minimal_symbols (elfread.c:1221)
==55015==    by 0x10171B27: elf_symfile_read (elfread.c:1264)
==55015==    by 0x1020F2A3: read_symbols (symfile.c:877)
==55015==    by 0x1020EC9B: syms_from_objfile_1 (symfile.c:1080)
==55015==    by 0x1020EC9B: syms_from_objfile (symfile.c:1096)
==55015==    by 0x1020EC9B: symbol_file_add_with_addrs (symfile.c:1193)
==55015==    by 0x1020F3F3: symbol_file_add_from_bfd (symfile.c:1282)
==55015==    by 0x1020F3F3: symbol_file_add (symfile.c:1297)
==55015==    by 0x1020F49B: symbol_file_add_main_1 (symfile.c:1322)
==55015==    by 0x10247F3B: catch_command_errors_const.constprop.5 (main.c:378)
==55015==    by 0x10248DDF: captured_main (main.c:1066)
==55015==    by 0x10242A5F: catch_errors (exceptions.c:506)
==55015==    by 0x10249507: gdb_main (main.c:1172)
==55015== 
done.
done.
(gdb) q
==55015== 
==55015== HEAP SUMMARY:
==55015==     in use at exit: 2,520,075 bytes in 25,371 blocks
==55015==   total heap usage: 58,711 allocs, 33,340 frees, 9,252,523 bytes
allocated
==55015== 
==55015== LEAK SUMMARY:
==55015==    definitely lost: 33,643 bytes in 11 blocks
==55015==    indirectly lost: 16,280 bytes in 5 blocks
==55015==      possibly lost: 404,864 bytes in 2,239 blocks
==55015==    still reachable: 2,065,288 bytes in 23,116 blocks
==55015==         suppressed: 0 bytes in 0 blocks
==55015== Rerun with --leak-check=full to see details of leaked memory
==55015== 
==55015== For counts of detected and suppressed errors, rerun with: -v
==55015== ERROR SUMMARY: 19 errors from 4 contexts (suppressed: 0 from 0)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/17968] [ppc64] SEGV in ppc64_elf_get_synthetic_symtab reading a separate debug file

[msebor at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17968

--- Comment #1 from Martin Sebor <msebor at redhat dot com> ---
The following test case reduced from a build of the kernel module in the
problem Description reproduces the SEGV with the top of trunk.  Tthough the
program faults in a different function, Valgrind reports the same Invalid read.

$ set -x && cat t.c && gcc -c -g t.c && cat t.lds && ld -r -T t.lds --build-id
-o t.ko t.o && cp t.ko t.sym.ko && objcopy --only-keep-debug t.ko t.ko.debug &&
strip --strip-debug t.ko && objcopy --add-gnu-debuglink=t.ko.debug t.ko &&
/build/gdb-fsf/gdb/gdb -q -batch t.sym.ko && /build/gdb-fsf/gdb/gdb -q -batch
t.ko; set +x
+ cat t.c
void foo (void) __attribute__ ((section (".bar")));
void foo (void) { }

+ gcc -c -g t.c
+ cat t.lds
SECTIONS {
  .foobar : { *(.bar) }
}
+ ld -r -T t.lds --build-id -o t.ko t.o
+ cp t.ko t.sym.ko
+ objcopy --only-keep-debug t.ko t.ko.debug
+ strip --strip-debug t.ko
+ objcopy --add-gnu-debuglink=t.ko.debug t.ko
+ /build/gdb-fsf/gdb/gdb -q -batch t.sym.ko
+ /build/gdb-fsf/gdb/gdb -q -batch t.ko
Segmentation fault

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/17968] [ppc64] SEGV in ppc64_elf_get_synthetic_symtab reading a separate debug file

[msebor at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17968

--- Comment #2 from Martin Sebor <msebor at redhat dot com> ---
The problem appears to be due to the change to gdb/elfread.c introduced in the
commit below:

commit 63524580f8372e38a6a62fd875a4252068c31150
Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Date:   Sun Apr 17 18:38:46 2011 +0000

    ...    
    gdb/
        Fix convert_code_addr_to_desc_addr for ppc64 files after eu-strip.
        * elfread.c (elf_symfile_read): New variable synth_abfd, pass it to
        bfd_get_synthetic_symtab.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/17968] [ppc64] SEGV in ppc64_elf_get_synthetic_symtab reading a separate debug file

[sergiodj at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17968

Sergio Durigan Junior <sergiodj at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jan.kratochvil at redhat dot com,
                   |                            |sergiodj at redhat dot com

--- Comment #3 from Sergio Durigan Junior <sergiodj at redhat dot com> ---
Adding Jan to the Cc list to keep him on the loop.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/17968] [ppc64] SEGV in ppc64_elf_get_synthetic_symtab reading a separate debug file

[cel at us dot ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17968

Carl E Love <cel at us dot ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cel at us dot ibm.com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/17968] [ppc64] SEGV in ppc64_elf_get_synthetic_symtab reading a separate debug file

[cel at us dot ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17968

--- Comment #4 from Carl E Love <cel at us dot ibm.com> ---
I was looking at this bug.  I am trying to reproduce it using the current gdb. 
So far I have not been able to reproduce it using a ppc64 module.  I played a
bit with the second test and also was not able to reproduce the issue. 

Is this still an issue?  If not, can we close the issue?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/17968] [ppc64] SEGV in ppc64_elf_get_synthetic_symtab reading a separate debug file

[will_schmidt at vnet dot ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17968

Will Schmidt <will_schmidt at vnet dot ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |will_schmidt at vnet dot ibm.com

--- Comment #5 from Will Schmidt <will_schmidt at vnet dot ibm.com> ---

I spun some older builds, and was not able to duplicate the reported
problem on anything recent.  (attempted 11.1, 10.2, 9.2, 8.0, 7.12 on a ppc64
system).  I wasn't able to build older releases for assorted reasons.

Per a review of the git logs, and comparing the dates, I suspect the reported
issue was resolved by this commit, on Feb 26, 2015.

"
commit 80c570537e380c1b8e48754c0ddbce2abcde2d00
Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Date:   Thu Feb 26 14:08:01 2015 +0100

    SEGV in ppc64_elf_get_synthetic_symtab reading a separate debug file
"

-- 
You are receiving this mail because:
You are on the CC list for the bug.