public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Bruno Larsen <blarsen@redhat.com>
To: Mikael Szreder <miksz574@student.liu.se>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH] gdb/solib-svr4.c: Fix segfault caused by NULL pointer
Date: Fri, 4 Mar 2022 09:35:54 -0300	[thread overview]
Message-ID: <14de2fb0-8018-6cf4-584f-168310f2c80a@redhat.com> (raw)
In-Reply-To: <DU0P191MB20333F5BF639A7C4AFBAE4A8A5059@DU0P191MB2033.EURP191.PROD.OUTLOOK.COM>

Hi Mikael

Thanks for looking into this.

On 3/4/22 07:54, Mikael Szreder via Gdb-patches wrote:
> Inside the function 'enable_break' there is a call to 'find_program_interpreter'.
> This function returns an empty vector when an ELF file does not contain
> an interpreter because the function 'read_program_header' header
> returns an empty vector on failure.
> 
> The call to 'interp_name_holder->data()' then returns NULL for an empty vector.
> This causes a segmentation fault down the line.

I see that interp_name_holder is a gdb::optional type. This makes me wonder, is there a good reason for find_name_program to return an instantiated empty byte_vector, instead of returning a non-instantiated gdb::optional? I could be missing something, but to me it seems to make gdb::optional redundant.

I'd also ask that the title be changed to something like "gdb/solib-svr4.c: Fix segfault caused by NULL pointer in function enable_break", as the current name is a bit generic.

> ---
>   gdb/solib-svr4.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
> index 69f2991f5e6..18bd712e061 100644
> --- a/gdb/solib-svr4.c
> +++ b/gdb/solib-svr4.c
> @@ -2204,7 +2204,7 @@ enable_break (struct svr4_info *info, int from_tty)
>        into the old breakpoint at symbol code.  */
>     gdb::optional<gdb::byte_vector> interp_name_holder
>       = find_program_interpreter ();
> -  if (interp_name_holder)
> +  if (interp_name_holder && interp_name_holder->size() != 0)
>       {
>         const char *interp_name = (const char *) interp_name_holder->data ();
>         CORE_ADDR load_addr = 0;


-- 
Cheers!
Bruno Larsen


  reply	other threads:[~2022-03-04 12:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-04 10:54 Mikael Szreder
2022-03-04 12:35 ` Bruno Larsen [this message]
2022-03-04 14:35 ` Tom Tromey
2022-03-04 16:13 ` Pedro Alves

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=14de2fb0-8018-6cf4-584f-168310f2c80a@redhat.com \
    --to=blarsen@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=miksz574@student.liu.se \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).