From: Andrew Burgess <aburgess@redhat.com>
To: "brandon.belew" <brandon.belew@zetier.com>, gdb-patches@sourceware.org
Cc: brandon.belew@zetier.com
Subject: Re: [PATCH] [PR corefiles/32441] Fix segfault if target_fileio_read_alloc fails
Date: Thu, 16 Jan 2025 16:51:12 +0000 [thread overview]
Message-ID: <87v7ueog73.fsf@redhat.com> (raw)
In-Reply-To: <hwjgyamsgplr1u.fsf@brandonb.zetier.com>
"brandon.belew" <brandon.belew@zetier.com> writes:
> Check for target_fileio_read_alloc failure in linux_fill_prpsinfo
> before dereferencing buffer. This fixes a segfault in the 'gcore'
> command when attached to certain remote targets.
> ---
> This is my first contribution to GDB, and my first use of
> git-send-email, so please let me know if this is formatted
> incorrectly! I initially submitted the bug and a v1 patch at
> https://sourceware.org/bugzilla/show_bug.cgi?id=32441 and received the
> following from Thiago Bauermann:
>
>> Thank you for the patch. In general it looks good to me, just a couple of minor
>> comments:
>>
>> 1. Since target_fileio_read_alloc () returns LONGEST, I think it's better if
>> the buf_len variable also has that type.
>
> I decided to stick with ssize_t for the variable, as this matches the
> usage elsewhere in linux-tdep.c in linux_info_proc (which already was
> correctly checking the length).
I think you should reconsider here. The function returns LONGEST, so
that's what should be used. GDB's general policy is to fix little
bugs like this as the code gets touched for other reasons.
Otherwise, I agree with Luis, this looks great. If you repost with the
description in the commit message we can get this merged.
Thanks,
Andrew
>
>> 2. GDB is (very) slowly transitioning from C to C++. We currently prefer to use
>> nullptr rather than NULL, so I suggest using this patch as an opportunity to
>> change NULL to nullptr in lines 1876, 1877 and 1879.
>
> I made the requested NULL -> nullptr changes.
>
> Let me know if this is good or if I need to make any changes in my
> workflow to adhere to GNU or gdb project conventions.
>
> gdb/linux-tdep.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c
> index d3452059ce2..c10c4c76451 100644
> --- a/gdb/linux-tdep.c
> +++ b/gdb/linux-tdep.c
> @@ -1867,17 +1867,17 @@ linux_fill_prpsinfo (struct elf_internal_linux_prpsinfo *p)
> /* The number of fields read by `sscanf'. */
> int n_fields = 0;
>
> - gdb_assert (p != NULL);
> + gdb_assert (p != nullptr);
>
> /* Obtaining PID and filename. */
> pid = inferior_ptid.pid ();
> xsnprintf (filename, sizeof (filename), "/proc/%d/cmdline", (int) pid);
> /* The full name of the program which generated the corefile. */
> - gdb_byte *buf = NULL;
> - size_t buf_len = target_fileio_read_alloc (NULL, filename, &buf);
> + gdb_byte *buf = nullptr;
> + ssize_t buf_len = target_fileio_read_alloc (nullptr, filename, &buf);
> gdb::unique_xmalloc_ptr<char> fname ((char *)buf);
>
> - if (buf_len < 1 || fname.get ()[0] == '\0')
> + if (buf_len < 1 || fname.get () == nullptr || fname.get ()[0] == '\0')
> {
> /* No program name was read, so we won't be able to retrieve more
> information about the process. */
> --
> 2.46.0
next prev parent reply other threads:[~2025-01-16 16:52 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-20 22:17 brandon.belew
2025-01-16 10:27 ` Luis Machado
2025-01-16 16:28 ` Brandon Belew
2025-01-16 16:51 ` Andrew Burgess [this message]
2025-01-16 17:36 ` Brandon Belew
2025-01-20 14:44 ` Andrew Burgess
2025-01-27 20:20 ` [PATCH v2] " Brandon Belew
2025-02-18 23:44 ` Brandon Belew
2025-02-28 11:03 ` Andrew Burgess
2025-03-04 13:47 ` [PATCH v3] " Brandon Belew
2025-03-09 4:17 ` [PATCH v2] " Joel Brobecker
2025-03-01 10:23 GDB 16.3 release - 2025-03-01 update Joel Brobecker
2025-03-03 14:23 ` Luis Machado
2025-03-04 3:07 ` Joel Brobecker
2025-03-03 15:08 ` Brandon Belew
2025-03-04 3:12 ` Joel Brobecker
2025-03-07 14:07 ` Tom Tromey
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=87v7ueog73.fsf@redhat.com \
--to=aburgess@redhat.com \
--cc=brandon.belew@zetier.com \
--cc=gdb-patches@sourceware.org \
/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