[Bug symtab/34149] [gdb/symtab] Recent regressions

simark at simark dot ca sourceware-bugzilla@sourceware.org
Thu May 14 20:03:53 GMT 2026


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

--- Comment #9 from Simon Marchi <simark at simark dot ca> ---
Ok, so I built with TSan, and I think it triggers it, although it's not a
concurrency issue.

(I did encounter a real TSan error about the "counters" global in complaints.c,
I should file a separate bug for that).

It's caught by _GLIBCXX_DEBUG (so glad I enable that):

(gdb) file
/home/simark/build/binutils-gdb-tsan/gdb/testsuite/outputs/gdb.dwarf2/debug-names-bad-cu-index/debug-names-bad-cu-index
Reading symbols from
/home/simark/build/binutils-gdb-tsan/gdb/testsuite/outputs/gdb.dwarf2/debug-names-bad-cu-index/debug-names-bad-cu-index...
/usr/include/c++/16.1.1/bits/stl_algo.h:1981:
In function:
    constexpr _FIter std::lower_bound(_FIter, _FIter, const _Tp&, _Compare) 
    [with _FIter = gnu_debug::_Safe_iterator<gnu_cxx::
    normal_iterator<unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter>*, 
    vector<unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter>, 
    allocator<unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter> > > >, 
    debug::vector<unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter> >, 
    random_access_iterator_tag>; _Tp = section_and_offset; _Compare = 
    dwarf2_find_unit(const section_and_offset&, 
    dwarf2_per_bfd*)::<lambda(const dwarf2_per_cu_up&, const 
    section_and_offset&)>]

Error: elements in iterator range [first, last) are not partitioned by the 
predicate __comp and value __val.

Objects involved in the operation:
    iterator "first" @ 0x7fffc4b86fc0 {
      type = gnu_cxx::normal_iterator<std::unique_ptr<dwarf2_per_cu,
dwarf2_per_cu_deleter>*, std::vector<std::unique_ptr<dwarf2_per_cu,
dwarf2_per_cu_deleter>, std::allocator<std::unique_ptr<dwarf2_per_cu,
dwarf2_per_cu_deleter> > > > (mutable iterator);
      state = dereferenceable (start-of-sequence);
      references sequence with type
'std::debug::vector<std::unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter>,
std::allocator<std::unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter> > >' @
0x726c00024178
    }
    iterator "last" @ 0x7fffc4b86ff0 {
      type = gnu_cxx::normal_iterator<std::unique_ptr<dwarf2_per_cu,
dwarf2_per_cu_deleter>*, std::vector<std::unique_ptr<dwarf2_per_cu,
dwarf2_per_cu_deleter>, std::allocator<std::unique_ptr<dwarf2_per_cu,
dwarf2_per_cu_deleter> > > > (mutable iterator);
      state = past-the-end;
      references sequence with type
'std::debug::vector<std::unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter>,
std::allocator<std::unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter> > >' @
0x726c00024178
    }

It happens here:

#4  0x00007f88a669ed9b in __gnu_debug::_Error_formatter::_M_error() const ()
from /usr/lib/libstdc++.so.6
#5  0x000056400d26a40e in std::lower_bound<[trim]
#6  0x000056400d2631a8 in dwarf2_find_unit (start=..., per_bfd=0x726c00023e00)
at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:18063
#7  0x000056400d1d8162 in build_and_check_cu_list_from_debug_names
(per_bfd=0x726c00023e00, map=..., section=...) at
/home/simark/src/binutils-gdb/gdb/dwarf2/read-debug-names.c:977
#8  0x000056400d1d82b7 in build_and_check_cu_lists_from_debug_names
(per_bfd=0x726c00023e00, map=..., dwz_map=...) at
/home/simark/src/binutils-gdb/gdb/dwarf2/read-debug-names.c:1003
#9  0x000056400d1d88cd in dwarf2_read_debug_names (per_objfile=0x725c00061c80)
at /home/simark/src/binutils-gdb/gdb/dwarf2/read-debug-names.c:1079


What happens is:

- this file has the DWARF 5 type units in a .debug_types section, which is not
correct (should be in .debug_info), but we still support it for some reason (we
should perhaps fix the DWARF assembler)
- we build the all_units vector from the CU and TU lists (function
create_all_units)
- all_units contains two units, [the CU, the TU], which maybe be considered
unsorted (in terms of all_units_less_than), if the "dwarf2_section_info *" for
.debug_types is less than the "dwarf2_section_info *" for .debug_info.
- build_and_check_cu_list_from_debug_names looks up the CU with
dwarf2_find_unit, which uses std::lower_bound, which expects the list to be
properly sorted
- because of that, dwarf2_find_unit sometimes doesn't find the CU, even if it's
there, and we see the error you get

I think the fix will be to do it in this order:

- create_all_units
- create_foreign_type_units_from_debug_names
- finalize_all_units (which sorts all_units)
- build_and_check_*

Can you test the patch below?

>From b74b3dd04366bbb54a5da1639647a8fe2c8fc4fa Mon Sep 17 00:00:00 2001
From: Simon Marchi <simon.marchi@polymtl.ca>
Date: Thu, 14 May 2026 16:03:07 -0400
Subject: [PATCH] patch debug names

Change-Id: I315f391605af549b55341a167683d2dc6203bcea
---
 gdb/dwarf2/read-debug-names.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/gdb/dwarf2/read-debug-names.c b/gdb/dwarf2/read-debug-names.c
index a062c1ad2562..8f1d3f44290b 100644
--- a/gdb/dwarf2/read-debug-names.c
+++ b/gdb/dwarf2/read-debug-names.c
@@ -1076,6 +1076,12 @@ dwarf2_read_debug_names (dwarf2_per_objfile
*per_objfile)
     }

   create_all_units (per_objfile);
+  create_foreign_type_units_from_debug_names (per_objfile->per_bfd, map);
+
+  /* create_foreign_type_units_from_debug_names may add more entries to the
+     ALL_UNITS vector, so it must be called before finalize_all_units.  */
+  finalize_all_units (per_objfile->per_bfd);
+
   if (!build_and_check_cu_lists_from_debug_names (per_bfd, map, dwz_map))
     return false;

@@ -1097,12 +1103,6 @@ dwarf2_read_debug_names (dwarf2_per_objfile
*per_objfile)
        return false;
     }

-  create_foreign_type_units_from_debug_names (per_objfile->per_bfd, map);
-
-  /* create_foreign_type_units_from_debug_names may add more entries to the
-     ALL_UNITS vector, so it must be called before finalize_all_units.  */
-  finalize_all_units (per_objfile->per_bfd);
-
   per_bfd->debug_aranges.read (per_objfile->objfile);

   /* There is a single address map for the whole index (coming from

base-commit: fd6e1324acd2036aca26b4a0776665ee4bf01ae5
-- 
2.54.0

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


More information about the Gdb-prs mailing list