Created attachment 12379 [details] testcase for sect_index_text crash When loading a shared library that has no .text section, and does not have either 1 or 2 segments, gdb will fail with "internal-error: sect_index_text not initialized". I've attached a minimal testcase. $ cat >test.c <<EOF int main() {} EOF $ gcc test.c ./libtestcase.so $ gdb ./a.out ... <snip> ... GNU gdb (GDB) 10.0.50.20200307-git ... <snip> ... Reading symbols from ./a.out... (gdb) r Starting program: /tmp/a.out ../../gdb/objfiles.h:524: internal-error: sect_index_text not initialized A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n)
Hello, Using gdb 7.12.1, I'm currently experiencing a very similar issue, if not exactly the same. You'll find attached a stack obtained from the core generated by gdb at its request on experiencing the following issue. Reading symbols from /usr/tmp_people/lps/tinony/dev/tina_lps42/Lib/libXm.so.4...done. Reading symbols from /usr/lib/x86_64-linux-gnu/libXt.so.6...(no debugging symbols found)...done. Reading symbols from /usr/lib/x86_64-linux-gnu/libX11.so.6...(no debugging symbols found)...done. Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Reading symbols from /lib/x86_64-linux-gnu/libcrypt.so.1...(no debugging symbols found)...done. Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...(no debugging symbols found)...done. Reading symbols from /usr/tmp_people/lps/tinony/dev/tina_lps42/Lib/libicuuc.so.64...(no debugging symbols found)...done. Reading symbols from /usr/tmp_people/lps/tinony/dev/tina_lps42/Lib/libicudata.so.64...../../gdb-7.12.1/gdb/symfile.c:969: internal-error: sect_index_text not initialized A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) n This is a bug, please report it. For instructions, see: <http://www.gnu.org/software/gdb/bugs/>. ../../gdb-7.12.1/gdb/symfile.c:969: internal-error: sect_index_text not initialized A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) y Command aborted. (gdb) q A debugging session is active. Inferior 1 [process 27615] will be detached. Quit anyway? (y or n) y
Created attachment 12421 [details] Stack of gdb when encountering the issue This file contains the stack obtained from the core which was produced by gdb when it encountered the "internal-error: sect_index_text not initialized"
I can confirm that this still happens on HEAD: $ ./gdb 25678 -ex r GNU gdb (GDB) 10.0.50.20200318-git Copyright (C) 2020 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. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from 25678... (No debugging symbols found in 25678) Starting program: /home/keiths/tmp/25678 ../../src/gdb/objfiles.h:524: internal-error: sect_index_text not initialized A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n)
As of now, and up to what I can understand, this issue seams to be triggered by libicudata.so.64, as with *very* similar source code using libicudata.so.59 I don't experience the issue. Fortunately enough, I may revert to this previous version for the sake of my current most urgent issue. But for some of our new features, this revert sounds a bit more tricky and we're eager to obtaining a gdb version compatible with libicudata.so.64 Thanks in advance.
Created attachment 12535 [details] Proposed patch to fix the problem From patch by Jeremie Courreges-Anglas: https://marc.info/?l=openbsd-ports&m=146569238229407&w=2 Needs a test case.
To reproduce this on Ubuntu, I needed -Wl,--no-as-needed. Otherwise, the executable wouldn't be linked with libtestcase.so. $ gcc test.c -Wl,--no-as-needed ./libtestcase.so -g3 -O0
Also reported in Gentoo as https://bugs.gentoo.org/724614
On gdb-9.2 test case from #comment1 fails as: """ $ x86_64-pc-linux-gnu-gcc test.c ./libtestcase.so $ gdb --quiet ./a.out Reading symbols from ./a.out... (gdb) r Starting program: /tmp/a.out ../../gdb-9.2/gdb/dwarf2read.c:8080: internal-error: sect_index_text not initialized A problem internal to GDB has been detected, further debugging may prove unreliable. """
I'm using GDB 9.2 on Arch Linux. I ran into this issue today ("../../gdb/symfile.c:886: internal-error: sect_index_text not initialized") and I can confirm that the proposed patch works for me. But the testcase fails with or without the patch.
I had kind of forgotten about this issue, thanks for bringing it up again. I did send this RFC in May to ask for opinions on how we should address the issue: https://sourceware.org/pipermail/gdb-patches/2020-May/168767.html There was no answer, but I'll take another look and see if I can propose an actual patch.
Hi Also using gdb 9.2, the fix proposed by Jeremie Courreges-Anglas liked in comment 5 works for my case. But before testing on gdb 9.2, I tried on gdb 8.3.1 and after double checking, for my case the fix doesn't work.
I see this when I dlopen() a shared library that has (Elf64_Ehdr.e_shnum == 0) : ===== GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git /build/gdb-MVZsgD/gdb-10.1/gdb/symfile.c:878: internal-error: sect_index_text not initialized A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) ===== Relying on the current libbfd, which looks only at ElfXX_Shdr (and not at ElfXX_Phdr{PT_DYNAMIC}), is not adequate when debugging execution. Neither the operating system {Linux kernel), nor the run-time dynamic linker (rtld or ld-linux.so} pays any attention to ElfXX_Shdr. Instead, execution is controlled entirely by the ElfXX_Phdr. In particular, the PT_DYNAMIC segment with its entries for PT_SYMTAB, PT_STRTAB, PT_GNU_HASH, PT_VERSYM, PT_VERNEED contain the same information that the SHT_DYNSYM, SHT_STRTAB, SHT_GNU_HASH, SHT_VERSYM, SHT_VERNEED sections may have once contained. So if ElfXX_Shdr cannot be found or do not look right, then libbfd and/or gdb should consult the ELFXX_Phdr{PT_DYNAMIC}.