From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 70BD01F46C for ; Wed, 22 Jan 2020 07:00:07 +0000 (UTC) Received: from localhost ([::1]:37670 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iu9zg-000178-Lg for normalperson@yhbt.net; Wed, 22 Jan 2020 02:00:04 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36273) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iu9qn-0005He-Me for bug-gnulib@gnu.org; Wed, 22 Jan 2020 01:50:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iu9qm-0008MI-8a for bug-gnulib@gnu.org; Wed, 22 Jan 2020 01:50:53 -0500 Received: from smtp.lrde.epita.fr ([163.5.55.2]:52716) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iu9qm-0008Kl-20 for bug-gnulib@gnu.org; Wed, 22 Jan 2020 01:50:52 -0500 Received: from [192.168.1.35] (lns-bzn-30-82-253-153-106.adsl.proxad.net [82.253.153.106]) by smtp.lrde.epita.fr (Postfix) with ESMTPSA id CDD674340E; Wed, 22 Jan 2020 07:50:49 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: fstrcmp: memory is not reclaimed on exit From: Akim Demaille In-Reply-To: <2875969.BTBdedgLeP@omega> Date: Wed, 22 Jan 2020 07:50:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <85BF43E8-5844-48B2-B7B9-F9BCA7F67E7A@lrde.epita.fr> References: <2875969.BTBdedgLeP@omega> To: Bruno Haible X-Mailer: Apple Mail (2.3445.104.11) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 163.5.55.2 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" Hi Bruno, > Le 20 janv. 2020 =C3=A0 22:57, Bruno Haible a =C3=A9cr= it : >=20 >>> Initialization: gl_tls_key_init (name, destructor); >>>=20 >>> A destructor is a function pointer of type 'void (*) (void *)', = called >>> when a thread exits, and taking the last per-thread value as = argument. It >>> is unspecified whether the destructor function is called when the = last >>> per-thread value is NULL. On some platforms, the destructor = function is >>> not called at all. >>=20 >> I can see that it's not expected to work on some platforms, but in = the >> case of the user the platform is fairly mainstream: >=20 > Meanwhile this destructor stuff even works on native Windows. The list = of > platforms where it does not work is very small (something like mingw = with > winpthreads, IIRC). Great! >> So I don't know what to do. Is this a red herring related to = Valgrind >> as a platform? >=20 > Do the threads still exist at the moment valgrind does its inventory = of left- > over memory? I don't know when it runs its stuff, but I expect, given where it = stands, that it does it as the latest possible instant. > In particular: > - Did you create threads, in which fstrcmp is run? If yes, are they = still > running? No, Bison does not use any threads. > - Or did you run fstrcmp in the main thread? Most likely valgrind = does its > inventory in the main thread, during exit(). This means that at = this point > the fstrcmp buffer for the main thread still exists. In other = words, you > should treat thread-local memory allocations for the main thread = like > static memory allocations (e.g. like in uniqstr.c). I agree, I would like to be able to explicitly release the memory. But I can't see any API to do that in fstrcmp.c. Is this one ok? I feel stupid to initialize the memory right before releasing, but I didn't find a means to check whether the tls memory was initialized. Thanks! commit eee1a395a841f7d1ae4388710c88c5dd3e047cc0 Author: Akim Demaille Date: Wed Jan 22 07:46:45 2020 +0100 fstrcmp: provide a means to explictly release resources =20 * lib/fstrcmp.h, lib/fstrcmp.c (fstrcmp_free): New. diff --git a/ChangeLog b/ChangeLog index 53a1fb435..10626e535 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2020-01-22 Akim Demaille + + fstrcmp: provide a means to explictly release resources. + * lib/fstrcmp.h, lib/fstrcmp.c (fstrcmp_free): New. + 2020-01-09 Bruno Haible =20 c32srtombs: Add tests. diff --git a/lib/fstrcmp.c b/lib/fstrcmp.c index c6a66389e..e8e02e856 100644 --- a/lib/fstrcmp.c +++ b/lib/fstrcmp.c @@ -73,6 +73,13 @@ keys_init (void) /* Ensure that keys_init is called once only. */ gl_once_define(static, keys_init_once) =20 +void +fstrcmp_free (void) +{ + gl_once (keys_init_once, keys_init); + gl_tls_key_destroy (buffer_key); + gl_tls_key_destroy (bufmax_key); +} =20 /* In the code below, branch probabilities were measured by Ralf = Wildenhues, by running "msgmerge LL.po coreutils.pot" with msgmerge 0.18 for = many diff --git a/lib/fstrcmp.h b/lib/fstrcmp.h index 92b67e34a..f3a57ecb6 100644 --- a/lib/fstrcmp.h +++ b/lib/fstrcmp.h @@ -38,6 +38,13 @@ extern double fstrcmp_bounded (const char *s1, const = char *s2, /* A shortcut for fstrcmp. Avoids a function call. */ #define fstrcmp(s1,s2) fstrcmp_bounded (s1, s2, 0.0) =20 +/* Explicitly release resources acquired in this thread. Regular + thread termination invokes it automatically, so it is typically not + needed to call it. However, in the case of the main thread, tools + such as Valgrind might report "leaks" if the memory is not + explicitly reclaimed first. */ +extern void fstrcmp_free (void); + #ifdef __cplusplus } #endif