Re: [RFA] PR python/18565 - make Frame.function work for inline frames

[Pedro Alves <palves at redhat dot com>]

On 07/25/2016 11:23 AM, Yao Qi wrote:
> 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.

I disagree.  In general, I think that up until the called function does a normal
return, the memory for output parameters is owned by the called function.
A normal return then transfers ownership of the output parameters' memory
to the caller.

So I think that it's find_frame_funname that should be responsible for making
sure that memory for output parameters is cleaned up on exception, or be
written in a way that never throws after the memory allocation, which it may be
already, but I haven't checked in detail.

Thanks,
Pedro Alves