From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19948 invoked by alias); 15 Nov 2016 15:56:56 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 19936 invoked by uid 89); 15 Nov 2016 15:56:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1818, pace X-HELO: mx1.redhat.com Subject: Re: [PATCH] malloc: Deprecate hook variables, __default_morecore, To: Joseph Myers References: <20161026150218.3F1A4439942E0@oldenburg.str.redhat.com> <11f59117-e5a4-4c62-739c-e05e01ee43b3@redhat.com> Cc: libc-alpha@sourceware.org From: Florian Weimer Message-ID: Date: Tue, 15 Nov 2016 15:56:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00501.txt.bz2 On 11/15/2016 04:39 PM, Joseph Myers wrote: > On Tue, 15 Nov 2016, Florian Weimer wrote: > >> In my opinion, the larger ecosystem already provides suitable replacements. >> >> * and all malloc hook functions are now deprecated. Future >> implementations of the mcheck- and mtrace-related functions will not >> have any effect, and glibc will stop calling the hook functions from >> its malloc implementation. Instead of mcheck and mtrace, developers >> should consider using valgrind. As a replacement for the hook >> functions, developers can interpose their own malloc implementation. > > I don't consider valgrind suitable for replacing the uses of mtrace in the > glibc testsuite (or other similar uses elsewhere for lightweight checking > for leaks). I completely agree. The above is for the NEWS file, for external use. For internal use, we still need a solution. (I have an mtrace-compatible interposition-based tracer almost finished, but it may not make the cut for the next release, and it may be superseded by DJ's work anyway.) I think we can run internal deprecation at a different pace than external deprecation. > I don't know enough about the functionality GDB expects from linking with > -lmcheck by default in development to know whether other malloc > improvements would provide similar checking by default or whether that > would also need GDB to provide its own malloc (again, I think valgrind is > vastly too heavyweight for using by default in GDB development). I wasn't aware that GDB developers are using this functionality. I'll ask them how critical it is to their needs. But I expect that there will be no glibc release which neither provides mcheck, nor provides an alternative. Thanks, Florian