From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-158071-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 92021 invoked by alias); 8 Aug 2019 17:42:03 -0000
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
Received: (qmail 92008 invoked by uid 89); 8 Aug 2019 17:42:03 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=
X-HELO: mx1.redhat.com
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Aug 2019 17:42:02 +0000
Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22])	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))	(No client certificate requested)	by mx1.redhat.com (Postfix) with ESMTPS id CC9D6C08E2AF;	Thu,  8 Aug 2019 17:42:00 +0000 (UTC)
Received: from f29-4.lan (ovpn-117-6.phx2.redhat.com [10.3.117.6])	by smtp.corp.redhat.com (Postfix) with ESMTPS id 96A6810001BD;	Thu,  8 Aug 2019 17:42:00 +0000 (UTC)
Date: Thu, 08 Aug 2019 17:42:00 -0000
From: Kevin Buettner <kevinb@redhat.com>
To: gdb-patches@sourceware.org
Cc: Tom Tromey <tom@tromey.com>, Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
Subject: Re: [PATCH] Fix access to uninitialized variable in fill_in_stop_func
Message-ID: <20190808104200.6a387ac8@f29-4.lan>
In-Reply-To: <87lfw360lt.fsf@tromey.com>
References: <20190808135443.10894-1-pedromfc@linux.ibm.com>	<87lfw360lt.fsf@tromey.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
X-SW-Source: 2019-08/txt/msg00208.txt.bz2

On Thu, 08 Aug 2019 11:14:22 -0600
Tom Tromey <tom@tromey.com> wrote:

> >>>>> "Pedro" == Pedro Franco de Carvalho <pedromfc@linux.ibm.com> writes:  
> 
> Pedro> This patch changes fill_in_stop_func to check the return value of
> Pedro> find_pc_partial_function before accessing the block pointer that is only
> Pedro> written by find_pc_partial_function if it returns a success status.  
> 
> Pedro> gdb/ChangeLog:
> Pedro> YYYY-MM-DD  Pedro Franco de Carvalho  <pedromfc@linux.ibm.com>  
> 
> Pedro> 	* infrun.c (fill_in_stop_func): Use return value of
> Pedro> 	find_pc_partial_function, remove comment.  
> 
> The comment for find_pc_partial_function says:
> 
>    nullptr is used as a return value for *BLOCK if no block is found. 
> 
> ... which implies to me that the function was intended to set *BLOCK
> unconditionally.  Perhaps Kevin could say, as I think he added the block
> parameter.

Yes, that was the intent, but unfortunately, that's not what's happening.

find_pc_partial_function contains the following return path...

  if (msymbol.minsym == NULL)
    {
      /* No available symbol.  */
      if (name != NULL)
	*name = 0;
      if (address != NULL)
	*address = 0;
      if (endaddr != NULL)
	*endaddr = 0;
      return 0;
    }

...which does not set *BLOCK.

I think I'd prefer to see...

      if (block != nullptr)
	*block = nullptr;

...added to find_pc_partial_function instead.

Kevin