This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] PR python/18565 - make Frame.function work for inline frames
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Tom Tromey <tom at tromey dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Mon, 25 Jul 2016 11:23:30 +0100
- Subject: Re: [RFA] PR python/18565 - make Frame.function work for inline frames
- Authentication-results: sourceware.org; auth=none
- References: <1466439050-11330-1-git-send-email-tom@tromey.com> <86ziqfq6sz.fsf@gmail.com> <8737o5kqtv.fsf@tromey.com>
Sorry, I missed this mail,
On Wed, Jun 22, 2016 at 7:42 PM, Tom Tromey <tom@tromey.com> wrote:
>>>>>> "Yao" == Yao Qi <qiyaoltc@gmail.com> writes:
>
> Yao> Tom Tromey <tom@tromey.com> writes:
>>> TRY
>>> {
>>> + char *funname;
>>> + enum language funlang;
>>> +
>>> FRAPY_REQUIRE_VALID (self, frame);
>>>
>>> - sym = find_pc_function (get_frame_address_in_block (frame));
>>> + find_frame_funname (frame, &funname, &funlang, &sym);
>>> + xfree (funname);
>>> }
>>> CATCH (except, RETURN_MASK_ALL)
>>> {
>
> Yao> Call xfree in CATCH block? Otherwise, patch is good to me.
>
> I looked at this. I think it's probably better as-is.
> My reasoning is that "funname" is initialized by the call to
> find_frame_funname and isn't otherwise used. So, putting the free where
> it appears now means that there is no gap between initialization and
> free.
>
The reason I suggested that way is that the exception may be thrown out in
find_frame_funname after the memory is allocated for funname, so we need
xfree in CATCH, and also need xfree afterwards.
--
Yao (齐尧)