From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 60F983858291; Tue, 19 Jul 2022 07:59:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 60F983858291 From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug symtab/29381] New: [gdb, debug-types, debug-names] read.h:309: internal-error: set_length: Assertion `m_length == length' failed. Date: Tue, 19 Jul 2022 07:59:09 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: symtab X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2022 07:59:09 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29381 Bug ID: 29381 Summary: [gdb, debug-types, debug-names] read.h:309: internal-error: set_length: Assertion `m_length =3D=3D 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-d= ebug-types/cpexprs-debug-types^M Reading symbols from /data/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.cp/cpexprs-d= ebug-types/cpexprs-debug-types...^M warning: Section .debug_aranges in /data/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.cp/cpexprs-d= ebug-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 =3D=3D 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). ...=20 The problem is three-fold. 1. The .debug_names index is rejected in dwarf2_read_debug_names because: ... if (map->tu_count !=3D 0) { /* We can only handle a single .debug_types when we have an index. */ if (per_bfd->types.size () !=3D 1) return false; ... there are TUs so the tu_count is > 0 but there's no .debug_types section (d= warf 5 puts the TUs in the .debug_info section) so the "per_bfd->types.size () != =3D 1" test fails. 2. After the index is rejected, we fall back to the cooked index, part of whic= h 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> 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 =3D 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_of= f)); return false; } } ... What the code really does is find duplicate offsets for CUs in all_comp_uni= ts. Which I suppose also means that duplicate debug_info_offsets in .debug_aran= ges 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 complai= nt: ... const auto per_cu_it =3D debug_info_offset_to_per_cu.find (sect_offset (debug_info_offse= t)); if (per_cu_it =3D=3D 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. --=20 You are receiving this mail because: You are on the CC list for the bug.=