From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1551 invoked by alias); 17 Nov 2016 13:00:52 -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 1528 invoked by uid 89); 17 Nov 2016 13:00:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1876 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: <1a524603-2966-df5a-edd9-8045aa256837@redhat.com> Date: Thu, 17 Nov 2016 13:00: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/msg00612.txt.bz2 On 11/16/2016 02:36 AM, Joseph Myers wrote: > On Tue, 15 Nov 2016, Florian Weimer wrote: > >>> 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. > > Well, I think mtrace (meaning the ability to run with tracing then run the > mtrace script to process the results, more than the functions to turn > tracing on and off) is similarly useful externally as a lightweight system > for tracing allocations and detecting leaks. And it is of course > documented in the manual. In my experience, it is not useful at all for finding the cause of leaks because you only get the address of the immediate caller of malloc, which is often a wrapper. The address is subject to ASLR as well. Based on the comments in this thread, I'm not sure if people find mtrace theoretically useful, or actually use it. :) In my proposed NEWS entry, I forgot to mention Address Sanitizer (as was pointed out in the GDB discussion). It has leak detection capabilities as well: ==7440==ERROR: LeakSanitizer: detected memory leaks Direct leak of 32 byte(s) in 1 object(s) allocated from: #0 0x7fc52f77097a in malloc (/lib64/libasan.so.2+0x9897a) #1 0x400703 in main (/tmp/a.out+0x400703) #2 0x7fc52f33757f in __libc_start_main (/lib64/libc.so.6+0x2057f) And it runs significantly faster than valgrind. Florian