[Bug symtab/29381] New: [gdb, debug-types, debug-names] read.h:309: internal-error: set_length: Assertion `m_length == length' failed.

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

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

            Bug ID: 29381
           Summary: [gdb, debug-types, debug-names] read.h:309:
                    internal-error: set_length: Assertion `m_length ==
                    length' failed.
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

When running test-case gdb.cp/cpexprs-debug-types/cpexprs-debug-types with
target board cc-with-debug-names on a system with gcc 12.1.1 (defaulting to
dwarf 5), I run into:
...
(gdb) file
/data/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.cp/cpexprs-debug-types/cpexprs-debug-types^M
Reading symbols from
/data/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.cp/cpexprs-debug-types/cpexprs-debug-types...^M
warning: Section .debug_aranges in
/data/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.cp/cpexprs-debug-types/cpexprs-debug-types
has duplicate debug_info_offset 0x0, ignoring .debug_aranges.^M
/data/vries/gdb_versions/devel/src/gdb/dwarf2/read.h:309: internal-error:
set_length: Assertion `m_length == length' failed.^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
----- Backtrace -----^M
ERROR: Couldn't load cpexprs-debug-types into GDB (GDB internal error).
... 

The problem is three-fold.

1.
The .debug_names index is rejected in dwarf2_read_debug_names because:
...
  if (map->tu_count != 0)
    {
      /* We can only handle a single .debug_types when we have an
         index.  */
      if (per_bfd->types.size () != 1)
        return false;
...
there are TUs so the tu_count is > 0 but there's no .debug_types section (dwarf
5 puts the TUs in the .debug_info section) so the "per_bfd->types.size () != 1"
test fails.

2.
After the index is rejected, we fall back to the cooked index, part of which is
building up all_comp_units.  The assumption there is that we start from
scratch, but in fact all_comp_units already has some elements, added when
reading the index.  This leads to the complaints and eventually the assert.

3.
The complaint is misleading.  It's issued during read_addrmap_from_aranges, but
the actual code does this:
...
  std::unordered_map<sect_offset,
                     dwarf2_per_cu_data *,
                     gdb::hash_enum<sect_offset>>
    debug_info_offset_to_per_cu;
  for (const auto &per_cu : per_bfd->all_comp_units)
    {
      /* A TU will not need aranges, and skipping them here is an easy
         way of ignoring .debug_types -- and possibly seeing a
         duplicate section offset -- entirely.  The same applies to
         units coming from a dwz file.  */
      if (per_cu->is_debug_types || per_cu->is_dwz)
        continue;

      const auto insertpair
        = debug_info_offset_to_per_cu.emplace (per_cu->sect_off,
                                               per_cu.get ());
      if (!insertpair.second)
        {
          warning (_("Section .debug_aranges in %s has duplicate "
                     "debug_info_offset %s, ignoring .debug_aranges."),
                   objfile_name (objfile), sect_offset_str (per_cu->sect_off));
          return false;
        }
    }
...

What the code really does is find duplicate offsets for CUs in all_comp_units.

Which I suppose also means that duplicate debug_info_offsets in .debug_aranges
are not actually detected.  Not sure if that is a big problem.

Note that the variable, debug_info_offset_to_per_cu is used in this complaint:
...
      const auto per_cu_it
        = debug_info_offset_to_per_cu.find (sect_offset (debug_info_offset));
      if (per_cu_it == debug_info_offset_to_per_cu.cend ())
        {
          warning (_("Section .debug_aranges in %s entry at offset %s "
                     "debug_info_offset %s does not exists, "
                     "ignoring .debug_aranges."),
                   objfile_name (objfile),
                   plongest (entry_addr - section->buffer),
                   pulongest (debug_info_offset));
          return false;
        }
...
and its usage here matches what we store in the variable.

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