From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 743573851C22 for ; Tue, 4 May 2021 08:27:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 743573851C22 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tdevries@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 90652B05D; Tue, 4 May 2021 08:27:43 +0000 (UTC) Subject: Re: [PATCH][gdb/guile] Don't allow libguile to change libgmp mem fns To: =?UTF-8?Q?Ludovic_Court=c3=a8s?= Cc: gdb-patches@sourceware.org, Andrew Burgess References: <20210503085428.GA20738@delia> <87sg33vare.fsf@gnu.org> From: Tom de Vries Message-ID: <78e4ebeb-5387-56ea-7d62-53a21c2c8f81@suse.de> Date: Tue, 4 May 2021 10:27:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <87sg33vare.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------30A3BD2C9B8123D3DB83BA57" Content-Language: en-US X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 08:27:46 -0000 This is a multi-part message in MIME format. --------------30A3BD2C9B8123D3DB83BA57 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 5/3/21 10:10 PM, Ludovic Courtès wrote: > Hi Tom, > > Tom de Vries skribis: > >> The fact that libguile tries to set the libgmp memory functions is a bug which >> should be fixed starting version v3.0.6. > > Yes. Building Guile with mini-GMP is recommended in 3.0.6 and later. > >> +++ b/gdb/guile/guile.c >> @@ -662,10 +662,32 @@ gdbscm_initialize (const struct extension_language_defn *extlang) >> { >> gdb::block_signals blocker; >> >> + /* There are libguile versions (f.i. v3.0.5) that by default call >> + mp_get_memory_functions during initialization to install custom >> + libgmp memory functions. This is considered a bug and should be >> + fixed starting v3.0.6. >> + Before gdb commit 880ae75a2b7 "gdb delay guile initialization until >> + gdbscm_finish_initialization", that bug had no effect for gdb, >> + because gdb subsequently called mp_get_memory_functions to install >> + its own custom functions in _initialize_gmp_utils. However, since >> + aforementioned gdb commit the initialization order is reversed, >> + allowing libguile to install a custom malloc that is incompatible >> + with the custom free as used in gmp-utils.c, resulting in a >> + "double free or corruption (out)" error. >> + Work around the libguile bug by saving the libgmp memory functions >> + before guile initialization, and restoring them afterwards. */ >> + void *(*alloc_func) (size_t); >> + void *(*realloc_func) (void *, size_t, size_t); >> + void (*free_func) (void *, size_t); >> + mp_get_memory_functions (&alloc_func, &realloc_func, &free_func); >> + >> /* scm_with_guile is the most portable way to initialize Guile. Plus >> we need to initialize the Guile support while in Guile mode (e.g., >> called from within a call to scm_with_guile). */ >> scm_with_guile (call_initialize_gdb_module, NULL); >> + >> + /* Restore libgmp memory functions. */ >> + mp_set_memory_functions (alloc_func, realloc_func, free_func); > > This code would lead to memory leaks because Guile would still think it > has its memory functions installed so it would never explicitly free GMP > memory. > > Instead, you can do: > > scm_install_gmp_memory_functions = 0; > > before the first call to ‘scm_with_guile’. That works with 3.0, 2.2, > and 2.0. > > HTH! It does, thanks for the review :) Committed as below. Thanks, - Tom --------------30A3BD2C9B8123D3DB83BA57 Content-Type: text/x-patch; charset=UTF-8; name="0001-gdb-guile-Don-t-allow-libguile-to-change-libgmp-mem-fns.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="0001-gdb-guile-Don-t-allow-libguile-to-change-libgmp-mem-fns"; filename*1=".patch" [gdb/guile] Don't allow libguile to change libgmp mem fns Since gdb commit 880ae75a2b7 "gdb delay guile initialization until gdbscm_finish_initialization" I'm running into: ... (gdb) print My_Var > 10.0^M free(): invalid pointer^M ERROR: GDB process no longer exists GDB process exited with wait status 5995 exp9 0 0 CHILDKILLED SIGABRT SIGABRT UNRESOLVED: gdb.ada/fixed_cmp.exp: gnat_encodings=all: print My_Var > 10.0 ... The problem is that both gdb and libguile try to set the libgmp memory functions, and since the gdb commit the ones from libguile are effective, which results in gdb freeing some memory in a way that is not compatible with the way that memory was actually allocated. The fact that libguile tries to set the libgmp memory functions is a bug which should be fixed starting version v3.0.6. Meanwhile, work around this in gdb by not allowing libguile to set the libgomp memory functions. Tested on x86_64-linux. gdb/ChangeLog: 2021-05-03 Tom de Vries PR guile/27806 * guile/guile.c (gdbscm_initialize): Don't let guile change libgmp memory functions. --- gdb/guile/guile.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/gdb/guile/guile.c b/gdb/guile/guile.c index bdf15cd498b..c6959f5b713 100644 --- a/gdb/guile/guile.c +++ b/gdb/guile/guile.c @@ -662,6 +662,22 @@ gdbscm_initialize (const struct extension_language_defn *extlang) { gdb::block_signals blocker; + /* There are libguile versions (f.i. v3.0.5) that by default call + mp_get_memory_functions during initialization to install custom + libgmp memory functions. This is considered a bug and should be + fixed starting v3.0.6. + Before gdb commit 880ae75a2b7 "gdb delay guile initialization until + gdbscm_finish_initialization", that bug had no effect for gdb, + because gdb subsequently called mp_get_memory_functions to install + its own custom functions in _initialize_gmp_utils. However, since + aforementioned gdb commit the initialization order is reversed, + allowing libguile to install a custom malloc that is incompatible + with the custom free as used in gmp-utils.c, resulting in a + "double free or corruption (out)" error. + Work around the libguile bug by disabling the installation of the + libgmp memory functions by guile initialization. */ + scm_install_gmp_memory_functions = 0; + /* scm_with_guile is the most portable way to initialize Guile. Plus we need to initialize the Guile support while in Guile mode (e.g., called from within a call to scm_with_guile). */ --------------30A3BD2C9B8123D3DB83BA57--