[Bug gdb/31497] New: gdb internal fatal error while opening a core dump; binary built with '-gsplit-dwarf'

[Bug gdb/31497] New: gdb internal fatal error while opening a core dump; binary built with '-gsplit-dwarf'

[sungdgdhtryrt at gmail dot com]

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

            Bug ID: 31497
           Summary: gdb internal fatal error while opening a core dump;
                    binary built with '-gsplit-dwarf'
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: sungdgdhtryrt at gmail dot com
  Target Milestone: ---

Created attachment 15406
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15406&action=edit
gdb crash dump

gdb internal fatal error while opening a core dump.

The binary is built with '-gsplit-dwarf', clang-16 using dwp. Dwarf version 5
is used.
Without split dwarf everything is good.

The error occurs from commit 65067f1c2c842f001017638c4fe53613d6656263 until
latest,
previous commits work well.


I did some debugging with gdb.core maybe it can help:

read_dwo_str_index (...): read.c:~19427
{
...
      bfd *abfd = reader->dwo_file->sections.str_offsets.get_bfd_owner ();
      const gdb_byte *p = reader->dwo_file->sections.str_offsets.buffer;

      -> p is NULL -> SIGSEGV in read_initial_length() below

      /* Header: Initial length.  */
      read_initial_length (abfd, p + bytes_read, &bytes_read);
...
}

In create_dwo_unit_in_dwp_v5(): ~10794
uint32_t offset is NULL (incorrect), but uint32_t size is correct,
see at the bottom the readelf dump section [ 6]
---

In create_dwp_hash_table(): ~10127
The offsets and sizes will be set:
      htab->section_pool.v5.offsets = ids_ptr + sizeof (uint32_t) * nr_columns;
      htab->section_pool.v5.sizes = ...

-> It seems htab->section_pool.v5.offsets will be zero after the assignment,
although sizes is correct.


Here is the readelf section dump of the dwp file:

readelf -W -S x.dwp
There are 10 section headers, starting at offset 0x861d0:

Section Headers:
  [Nr] Name                   Type            Address          Off    Size   ES
Flg Lk Inf Al
  [ 0]                        NULL            0000000000000000 000000 000000 00
     0   0  0
  [ 1] .strtab                STRTAB          0000000000000000 086138 000091 00
     0   0  1
  [ 2] .debug_loclists.dwo    PROGBITS        0000000000000000 000040 0000af 00
  E  0   0  1
  [ 3] .debug_abbrev.dwo      PROGBITS        0000000000000000 0000ef 00116b 00
  E  0   0  1
  [ 4] .debug_rnglists.dwo    PROGBITS        0000000000000000 00125a 000151 00
  E  0   0  1
  [ 5] .debug_str.dwo         PROGBITS        0000000000000000 0013ab 05703c 01
MSE  0   0  1

  [ 6] .debug_str_offsets.dwo PROGBITS        0000000000000000 0583e7 0057f8 00
  E  0   0  1
      --- gdb/dwarf2/read.c:10821 [create_dwo_unit_in_dwp_v5] -> size=0x57f8
correct but offset=0 wrong

  [ 7] .debug_info.dwo        PROGBITS        0000000000000000 05dbdf 0284dd 00
  E  0   0  1
  [ 8] .debug_cu_index        PROGBITS        0000000000000000 0860bc 000064 00
     0   0  1
  [ 9] .symtab                SYMTAB          0000000000000000 086120 000018 18
     1   1  8

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

[Bug gdb/31497] gdb internal fatal error while opening a core dump; binary built with '-gsplit-dwarf'

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
>       -> p is NULL -> SIGSEGV in read_initial_length() below

I think this means the section wasn't read in for some reason.
This is probably where I would start investigating.

One thing I notice is that read_str_index ensures that the
section is read in:

  str_section->read (objfile);
  str_offsets_section->read (objfile);

However, read_dwo_str_index does not do this.

I think I'd expect the section to be read in by dwarf2_locate_dwo_sections
or dwarf2_locate_v2_dwp_sections or dwarf2_locate_v5_dwp_sections, though.
(Depending on which file it comes from, I didn't look too deeply here...)

Could you see if one of those is hit and reads the section?
Maybe there's some error.  Or maybe just adding the calls to
read_dwo_str_index will fix it, this seems like an oversight
in the commit you pointed out.

>   [ 6] .debug_str_offsets.dwo PROGBITS        0000000000000000 0583e7 0057f8 00   E  0   0  1
>       --- gdb/dwarf2/read.c:10821 [create_dwo_unit_in_dwp_v5] -> size=0x57f8 correct but offset=0 wrong

The offset from 'readelf -WS' is the offset in the file.
I'm not sure but I doubt it's the same as the offsets mentioned
in create_dwp_hash_table.

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

[Bug gdb/31497] gdb internal fatal error while opening a core dump; binary built with '-gsplit-dwarf'

[sam at gentoo dot org]

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

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org

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

[Bug gdb/31497] gdb internal fatal error while opening a core dump; binary built with '-gsplit-dwarf'

[sungdgdhtryrt at gmail dot com]

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

--- Comment #2 from Hans <sungdgdhtryrt at gmail dot com> ---
Thank you for your very valuable advice. Your assumption about the
missing read for the str_offset section was correct. Adding a read in
read_dwo_str_index() prevents the crash and gdb is happy.
Although the read will be called twice now in read_dwo_str_index() and
read_str_index().

Thanks again for your help.


diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 4afb026b8ce..a54e783d614 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -17483,6 +17483,12 @@ read_dwo_str_index (const struct die_reader_specs
*reader, ULONGEST str_index)
         so assume the .debug_str_offsets section is DWARF5 as well, and
         parse the header.  FIXME: Parse the header only once.  */
       unsigned int bytes_read = 0;
+
+      // @@@
+      struct objfile *objfile = reader->cu->per_objfile->objfile;
+      reader->dwo_file->sections.str_offsets.read (objfile);
+      // @@@
+
       bfd *abfd = reader->dwo_file->sections.str_offsets.get_bfd_owner ();
       const gdb_byte *p = reader->dwo_file->sections.str_offsets.buffer;

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

[Bug gdb/31497] gdb internal fatal error while opening a core dump; binary built with '-gsplit-dwarf'

[tromey at sourceware dot org]

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

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
Re-reading is no problem, section::read is idempotent.

I wonder if we have enough information to write a test case.
From the stack trace I'd guess this is happening during
symtab expansion.  So the core file shouldn't be needed,
it might reproduce with just any old small test case with
the appropriate compiler & flags, and "gdb -readnow"...

If you want to send it as a gdb patch, see:
https://sourceware.org/gdb/wiki/ContributionChecklist

FWIW I think gdb should move away from lazily reading
section info and back toward reading it when the file is
opened.  This would also eliminate this bug.

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

[Bug gdb/31497] gdb internal fatal error while opening a core dump; binary built with '-gsplit-dwarf'

[sungdgdhtryrt at gmail dot com]

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

--- Comment #4 from Hans <sungdgdhtryrt at gmail dot com> ---
Indeed the core file is not necessary to provoke the bug. Here is a minimal
setup for the bug to occur.

cat > main.cpp << EOF
#include <stdio.h>

int main() {
        printf("hello world\n");
        return 0;
}
EOF

clang++-16 -g -gsplit-dwarf -c main.cpp -o main.o
clang++-16 main.o -o main
llvm-dwp-16 -e main -o main.dwp

<path to custom built gdb> ./main

clang++-16 tooling uses dwarf version 5 by default. The "--readnow" option is
not necessary.

Thank you again for the hint. I will try to send a gdb patch for this.

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

[Bug gdb/31497] gdb internal fatal error while opening a core dump; binary built with '-gsplit-dwarf'

[tromey at sourceware dot org]

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

--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
Thank you.
Really that original commit you identified should have come
with a test.

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