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.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 0F8AB1F466 for ; Mon, 20 Jan 2020 21:58:14 +0000 (UTC) Received: from localhost ([::1]:44512 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1itf3k-0000Qg-Kk for normalperson@yhbt.net; Mon, 20 Jan 2020 16:58:12 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50508) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1itf3g-0000QT-Qz for bug-gnulib@gnu.org; Mon, 20 Jan 2020 16:58:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1itf3f-0004dD-N2 for bug-gnulib@gnu.org; Mon, 20 Jan 2020 16:58:08 -0500 Received: from mo6-p00-ob.smtp.rzone.de ([2a01:238:20a:202:5300::7]:27683) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1itf3f-0004cG-2d for bug-gnulib@gnu.org; Mon, 20 Jan 2020 16:58:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1579557482; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=Fxz005/nWd/kP7SkmOsckAYRk7HBYsRYuz+/8Z0gdP4=; b=J8WX+gwLdUS+JflDXgM8muLdi25Kr4D9k6beBQ9ePPLhQ8nfdu1fw+NEkVz849ZK0B lT6NhsvXEDDSBd5yv2jZ5Q6zCylu2ODyGZ72Bp3ApugDd/g951MvsrUumWGg/jQlXFnS hedA7ve5JFWrl17p57+Xb6/D5oPnSgogCsrxhGTD3iMjcThUc8LN/xzruM/sPcH61qoA BIyuvJeaIszzQp+av8rmQw2SIhR8Z39ot8vq+poXuZbjmSnMA9YD3PoM9MlsgA3aEsun sIJL4n1Rl3eLi4R2O5lwSVVenhBX2eWmdWe/YcbjhkrbPPmvRn0LFPd/PJXES38g3LfA jabA== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOH6fzxfs=" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 46.1.5 DYNA|AUTH) with ESMTPSA id 506e28w0KLvt2yb (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Mon, 20 Jan 2020 22:57:55 +0100 (CET) From: Bruno Haible To: bug-gnulib@gnu.org Subject: Re: fstrcmp: memory is not reclaimed on exit Date: Mon, 20 Jan 2020 22:57:55 +0100 Message-ID: <2875969.BTBdedgLeP@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-171-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:238:20a:202:5300::7 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: Akim Demaille Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" Hi Akim, > > +==2837387== 320 bytes in 1 blocks are still reachable in loss record 1 of 1 > > +==2837387== at 0x483A80B: malloc (vg_replace_malloc.c:309) > > +==2837387== by 0x117CFC: xmalloc (xmalloc.c:41) > > +==2837387== by 0x11B743: UnknownInlinedFun (xalloc.h:103) > > +==2837387== by 0x11B743: fstrcmp_bounded (fstrcmp.c:208) > > which points to fstrcmp's allocation of its per-thread internal buffer. Correct. This is the per-thread buffer. > AFAICT, glthread takes care of reclaiming the memory when the thread > exits, that's the whole point of the "free" in the first line of the > body here: > > > static void > > keys_init (void) > > { > > gl_tls_key_init (buffer_key, free); > > gl_tls_key_init (bufmax_key, NULL); > > /* The per-thread initial values are NULL and 0, respectively. */ > > } > > glthread/tls.h reads > > > Initialization: gl_tls_key_init (name, destructor); > > > > 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. > > 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: 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). > So I don't know what to do. Is this a red herring related to Valgrind > as a platform? Do the threads still exist at the moment valgrind does its inventory of left- over memory? In particular: - Did you create threads, in which fstrcmp is run? If yes, are they still running? - 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). Bruno