From: Tom Tromey <tromey@adacore.com>
To: Simon Marchi <simark@simark.ca>
Cc: Tom Tromey <tromey@adacore.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Avoid crash in dwarf2/read.c:determine_prefix
Date: Fri, 01 May 2026 10:29:07 -0600 [thread overview]
Message-ID: <87340bhz58.fsf@tromey.com> (raw)
In-Reply-To: <fab51871-9768-4d0b-afb6-1fe6515ecbe1@simark.ca> (Simon Marchi's message of "Thu, 23 Apr 2026 22:40:13 -0400")
>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:
Simon> On 2026-04-23 14:52, Tom Tromey wrote:
>> I found a gdb crash when using some changes to gnat-llvm to have it
>> emit unqualified names in the DWARF. The crash happens because
>> determine_prefix does this:
>>
>> return dwarf2_full_name (nullptr, parent, cu);
>>
>> However, dwarf2_full_name can return NULL, causing a crash in the
>> caller.
>>
>> The particular DWARF causing this is pretty strange -- it is a
>> function nested inside another nameless function. This may be a bug
>> in gnat-llvm, something I plan to investigate.
>>
>> Meanwhile, gdb shouldn't crash. This patch changes determine_prefix
>> to avoid possible crashes here, by following its contract and not
>> returning NULL.
>>
>> I'm not sure if it's worthwhile to write a test case for this.
Simon> Seems fine. Did you go around and check if other calls to
Simon> dwarf2_full_name handled nullptr correctly? Most of them do, but others
Simon> seem like they would have a problem if dwarf2_full_name returned
Simon> nullptr. Or perhaps if in some cases we can prove that dwarf2_full_name
Simon> can't return nullptr, then we could use a gdb_assert.
I didn't generally look. Looking now though they generally seem fine.
Really what we should do is rewrite all the name computation code. It's
overly convoluted and confusing, and the cooked indexer proved that a
lot of the hair isn't needed.
Tom
prev parent reply other threads:[~2026-05-01 16:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-23 18:52 Tom Tromey
2026-04-24 2:40 ` Simon Marchi
2026-05-01 16:29 ` Tom Tromey [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87340bhz58.fsf@tromey.com \
--to=tromey@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=simark@simark.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox