From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32116 invoked by alias); 25 Jul 2016 15:01:48 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 32094 invoked by uid 89); 25 Jul 2016 15:01:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=face X-HELO: gproxy1-pub.mail.unifiedlayer.com Received: from gproxy1-pub.mail.unifiedlayer.com (HELO gproxy1-pub.mail.unifiedlayer.com) (69.89.25.95) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with SMTP; Mon, 25 Jul 2016 15:01:37 +0000 Received: (qmail 4609 invoked by uid 0); 25 Jul 2016 15:01:33 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy1.mail.unifiedlayer.com with SMTP; 25 Jul 2016 15:01:33 -0000 Received: from box522.bluehost.com ([74.220.219.122]) by cmgw4 with id P31V1t0062f2jeq0131YNR; Mon, 25 Jul 2016 09:01:33 -0600 X-Authority-Analysis: v=2.1 cv=TIHWFTVa c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=PnD2wP_eR3oA:10 a=C6ZbYQPAFpEA:10 a=cAmyUtKerLwA:10 a=qjnw91Ng0VQocgNPiCwA:9 Received: from [75.171.160.169] (port=39840 helo=pokyo) by box522.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_2) (envelope-from ) id 1bRhNo-0008N6-Ql; Mon, 25 Jul 2016 09:01:28 -0600 From: Tom Tromey To: Pedro Alves Cc: Yao Qi , Tom Tromey , "gdb-patches\@sourceware.org" Subject: Re: [RFA] PR python/18565 - make Frame.function work for inline frames References: <1466439050-11330-1-git-send-email-tom@tromey.com> <86ziqfq6sz.fsf@gmail.com> <8737o5kqtv.fsf@tromey.com> Date: Mon, 25 Jul 2016 15:01:00 -0000 In-Reply-To: (Pedro Alves's message of "Mon, 25 Jul 2016 12:04:16 +0100") Message-ID: <87bn1lu5h9.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Identified-User: {36111:box522.bluehost.com:elynrobi:tromey.com} {sentby:smtp auth 75.171.160.169 authed with tom+tromey.com} X-Exim-ID: 1bRhNo-0008N6-Ql X-Source-Sender: (pokyo) [75.171.160.169]:39840 X-Source-Auth: tom+tromey.com X-Email-Count: 0 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTIyLmJsdWVob3N0LmNvbQ== X-SW-Source: 2016-07/txt/msg00335.txt.bz2 Yao> The reason I suggested that way is that the exception may be thrown Yao> out in find_frame_funname after the memory is allocated for Yao> funname, so we need xfree in CATCH, and also need xfree afterwards. Pedro> I disagree. In general, I think that up until the called function does a normal Pedro> return, the memory for output parameters is owned by the called function. Pedro> A normal return then transfers ownership of the output parameters' memory Pedro> to the caller. Pedro> So I think that it's find_frame_funname that should be responsible for making Pedro> sure that memory for output parameters is cleaned up on exception, or be Pedro> written in a way that never throws after the memory allocation, which it may be Pedro> already, but I haven't checked in detail. I agree with this. I've just looked into the function and its callers. Most cases in find_frame_funname clearly set *funname in a spot where an exception cannot occur. The one iffy case is: *funname = xstrdup (SYMBOL_PRINT_NAME (func)); [...] if (*funlang == language_cplus) { /* It seems appropriate to use SYMBOL_PRINT_NAME() here, to display the demangled name that we already have stored in the symbol table, but we stored a version with DMGL_PARAMS turned on, and here we don't want to display parameters. So remove the parameters. */ char *func_only = cp_remove_params (*funname); I'm not 100% sure that cp_remove_params cannot throw. However, it's simple to deal with this by adding a cleanup in find_frame_funname. I'm happy to do this if desired. Another approach might be to have a free_current_contents cleanup at the start of find_frame_funname and discard it at the exit. This would maybe make it a bit safer in the face of future changes. Alternatively, if we need a try/catch in the caller to possibly free the function name, then several other callers are incorrect (ada-lang.c and stack.c). Tom