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=-4.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW, 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 BCBB11F45E for ; Wed, 19 Feb 2020 14:07:46 +0000 (UTC) Received: from localhost ([::1]:53228 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4Q0v-0000Gv-Da for normalperson@yhbt.net; Wed, 19 Feb 2020 09:07:45 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45533) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4Q0q-00009d-Ip for bug-gnulib@gnu.org; Wed, 19 Feb 2020 09:07:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j4Q0p-0004ZG-Dl for bug-gnulib@gnu.org; Wed, 19 Feb 2020 09:07:40 -0500 Received: from smtp.lrde.epita.fr ([163.5.55.2]:45884) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j4Q0p-0004Ye-7v for bug-gnulib@gnu.org; Wed, 19 Feb 2020 09:07:39 -0500 Received: from [172.20.10.14] (unknown [37.165.81.225]) by smtp.lrde.epita.fr (Postfix) with ESMTPSA id D038E4329D; Wed, 19 Feb 2020 15:07:36 +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: <5090405.yQzE4uMHgr@omega> Date: Wed, 19 Feb 2020 15:07:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4DEA13FA-AF66-4E30-88F4-C51C2143C86F@lrde.epita.fr> References: <2875969.BTBdedgLeP@omega> <85BF43E8-5844-48B2-B7B9-F9BCA7F67E7A@lrde.epita.fr> <5090405.yQzE4uMHgr@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 16 f=C3=A9vr. 2020 =C3=A0 13:52, Bruno Haible a = =C3=A9crit : >=20 > Hi Akim, >=20 > Sorry for the delay. You look busy :) >> +void >> +fstrcmp_free (void) >> +{ >> + gl_once (keys_init_once, keys_init); >> + gl_tls_key_destroy (buffer_key); >> + gl_tls_key_destroy (bufmax_key); >> +} >=20 > This workaround is insufficient, since POSIX [2] says that > "It is the responsibility of the application to free any application > storage or perform any cleanup actions for data structures related > to the deleted key or associated thread-specific data in any = threads" >=20 > In other words, pthread_key_delete is not guaranteed to call the = destructor > of 'buffer_key'. The gnulib test (tests/test-tls.c functions = test_tls_dtorcheck1 > and test_tls_dtorcheck2) verifies that the destructor gets called, but = only > for threads !=3D main thread, and you are interested in the main = thread > particularly. Most likely, in this test, the destructor gets called = when the > thread exits [3], not when pthread_key_delete gets called. Thanks for the details. The main thread is really not like the others. > This patch, however, should work. >=20 >=20 > 2020-02-16 Bruno Haible >=20 > fstrcmp: Add API to clean up resources. > Reported by Akim Demaille in > = . > * lib/fstrcmp.h (fstrcmp_free_resources): New declaration. > * lib/fstrcmp.c (fstrcmp_free_resources): New function. It looks good to me, thanks!=