Re: [PATCH 3/3] gdb/dwarf: fix crash when .gdb_index contains Rust legacy mangled names

[Simon Marchi <simon.marchi@polymtl.ca>]

On 10/6/26 7:01 AM, Andrew Burgess wrote:
> simon.marchi@polymtl.ca writes:
> 
>> From: Simon Marchi <simon.marchi@polymtl.ca>
>>
>> PR 34707 reports that loading the separate debug file of
>> /usr/lib/libglycin-2.so from Arch Linux crashes GDB (when built with
>> -D_GLIBCXX_DEBUG):
>>
>>     $ ./gdb -q -nx --data-directory data-directory $(DEBUGINFOD_URLS=https://debuginfod.archlinux.org debuginfod-find debuginfo /usr/lib/libglycin-2.so)
>>     /usr/include/c++/16/string_view:291: ... Assertion 'this->_M_len > 0' failed.
>>
>> This catches a case of calling string_view::back() when the string_view is
>> empty.
>>
>> The file in question contains a .gdb_index with some Rust symbol names that are
>> mangled with the legacy mangling style.
>>
>> The legacy mangling style was the default one until the Rust 1.97 release
>> in July 2026, so it's still very much in use, even though it's called
>> "legacy".
>>
>> Source: https://blog.rust-lang.org/2026/07/09/Rust-1.97.0/
>>
>> An example of a problematic symbol is:
>>
>>     _ZN4core3ptr271drop_in_place$LT$core..iter..adapters..filter..Filter$LT$alloc..vec..into_iter..IntoIter$LT$core..net..socket_addr..SocketAddr$GT$$C$zbus..address..transport..tcp..Tcp..connect..$u7b$$u7b$closure$u7d$$u7d$..$u7b$$u7b$closure$u7d$$u7d$..$u7b$$u7b$closure$u7d$$u7d$$GT$$GT$17h57c03bb201e55682E
>>
>> Method mapped_gdb_index::build_name_components attempts to split the
>> demangled fully-qualified symbol names into parts (it does not know in
>> advance whether a symbol name is a mangled (linkage) name or a demangled
>> one).
>>
>> Since this name does not match the C++ and Ada special cases, it falls into
>> the DOT_STYLE else:
>>
>>     components = split_name (name, split_style::DOT_STYLE);
>>
>> Because of the consecutive dots in the symbol name, `components` (an
>> std::vector<std::string_view>) contains some empty components.  Some code
>> later calls .back() on one of those empty string_views, which is invalid.
>>
>> It seems like it's only caught when gdb is built with _GLIBCXX_DEBUG /
>> _GLIBCXX_ASSERTIONS, which apparently is the case for the official Arch
>> Linux packages.
>>
>> I can't think of a pretty way to fix this.  Since we don't have a flag that
>> tells us whether a name is a linkage name or not, we can only make some
>> educated guesses.
>>
>> This patch fixes the problem by looking for empty components in the vector.
>> If there are, we assume that we are probably looking at a Rust legacy
>> mangled symbol name, or at the very least not a fully qualified demangled
>> Go (or whatever) symbol.  The name is then treated like other names without
>> separators (a single component with an unknown language).
>>
>> This is a regression introduced by commit 486bc5ac812f ("Rewrite the
>> .gdb_index reader").  Before that, the reader only split names on "::" and
>> "__".  This is new in the GDB 18.1 release, so this patch would be a
>> candidate for the gdb-18-branch.
>>
>> Add a gdb.dwarf2 test that builds a Rust CU with such a linkage name, adds
>> an index using gdb-add-index, and verifies that GDB can load it and find
>> the function.  The test is done with both .gdb_index and .debug_names,
>> although only the .gdb_index reader was affected.  Like the original
>> crash, the test only fails without the fix if GDB is built with libstdc++
>> assertions.
>>
>> One last thing, I don't know if it's expected for Rust mangled names to
>> appear in the index.  For C++, index-write.c does not write them:
>>
>>       else if (entry->lang == language_cplus
>> 	       && (entry->flags & IS_LINKAGE) != 0)
>> 	{
>> 	  /* GDB never put C++ linkage names into .gdb_index.  The
>> 	     theory here is that a linkage name will normally be in
>> 	     the minimal symbols anyway, so including it in the index
>> 	     is usually redundant -- and the cases where it would not
>> 	     be redundant are rare and not worth supporting.  */
>> 	  continue;
>> 	}
>>
>> Perhaps this is the real root of the problem: maybe those names should not
>> have been in the index in the first place, if the same rationale applies to
>> Rust.  We could make that change, but even if we do, there are already
>> indexes out there with those mangled names, so we have to handle them.
> 
> I agree being defensive on the read side is a good idea.  Even if these
> names were not intended to be in the index, and GDB had never emitted
> them, there's nothing to stop some other tool generating an index, and
> that tool might emit these names.  Conclusion: GDB should treat the
> index as untrusted input.
> 
> I actually started looking at making some fixes in this area -- not this
> particular fix, but others in this area -- the fixes were easy, but
> writing tests was taking some time.  It's a work in progress.
> 
> I agree that this could be merged to master and gdb-18-branch.
> 
> Approved-By: Andrew Burgess <aburgess@redhat.com>

Thanks a lot for the reviews.  I will give Tom Tromey some time if he
wants to look at this, since DWARF and Rust are some of his areas of
expertise.

Simon