From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87132 invoked by alias); 17 Nov 2016 14:50:41 -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 87084 invoked by uid 89); 17 Nov 2016 14:50:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=perturb, heavier, Hx-exchange-antispam-report-cfa-test:6043046, messes X-HELO: esa1.cray.iphmx.com X-Cray-OBMMKR: 1433258124 9976191 From: Steve Vormwald To: Florian Weimer , Joseph Myers CC: "libc-alpha@sourceware.org" Subject: Re: [PATCH] malloc: Deprecate hook variables, __default_morecore, Date: Thu, 17 Nov 2016 14:50:00 -0000 Message-ID: References: <20161026150218.3F1A4439942E0@oldenburg.str.redhat.com> <11f59117-e5a4-4c62-739c-e05e01ee43b3@redhat.com> ,<1a524603-2966-df5a-edd9-8045aa256837@redhat.com> In-Reply-To: <1a524603-2966-df5a-edd9-8045aa256837@redhat.com> authentication-results: spf=none (sender IP is ) smtp.mailfrom=sdvormwa@cray.com; x-microsoft-exchange-diagnostics: 1;DM5PR11MB1532;7:0cnAlTPL/gIGZYVmKPR3WiwsRqbf3zzXeuWG8bsU71D1+lgdybYu1AFJf+ZUONTWThnBmbV1cmMg2xNTfl7OZa120vbKK4b1MMS0vUsumoBReClEk+aJNE67dbVlst5hMyHorSjMndQpVsYBQgPQ5B826GLqDo6KIzzIM9ptgmpEAtJPwBAQbr5SP4wQqV2O6t0xDhVzVZLqC5gzrYqrVl2SFxGfdWbplnC8eTZkPY8iCjYHbmTyWwwjLh9HRVGns/JwhjYu6imywStHMau26aFDrcmoIYxqoCKVoxhGqCh28VVPhfWBijm1vWfNdUbWK/ry0woBRXensJC1q42n2LR2h9e+CFKexdAJzr3Kg4g= x-ms-office365-filtering-correlation-id: f9bfe0c1-828a-4072-37cf-08d40ef90792 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR11MB1532; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6060326)(6040281)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041223)(6061324)(6043046);SRVR:DM5PR11MB1532;BCL:0;PCL:0;RULEID:;SRVR:DM5PR11MB1532; x-forefront-prvs: 01294F875B x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(7916002)(189002)(24454002)(199003)(377454003)(4326007)(7696004)(105586002)(101416001)(106116001)(106356001)(68736007)(93886004)(6116002)(7846002)(305945005)(66066001)(3280700002)(86362001)(33656002)(97736004)(6506003)(8936002)(8676002)(2900100001)(9686002)(92566002)(102836003)(3846002)(77096005)(229853002)(54356999)(2950100002)(7736002)(99286002)(87936001)(74316002)(5001770100001)(81156014)(76576001)(81166006)(122556002)(50986999)(2906002)(3660700001)(189998001)(5660300001)(76176999);DIR:OUT;SFP:1102;SCL:1;SRVR:DM5PR11MB1532;H:DM5PR11MB1531.namprd11.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2016 14:50:10.1129 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e7b8488a-c0cd-4614-aae1-996bfabec247 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1532 X-OriginatorOrg: cray.com X-SW-Source: 2016-11/txt/msg00627.txt.bz2 On 11/17/2016 08:00 AM, Florian Weimer wrote: > 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. :) I make use of mtrace extensively when debugging oomkills on Cray systems. Traditional memory leaks are typically not as big a problem as heap fragmentation. Special hardware needs require non-default mallopt settings, notably severly restricting use of mmap, so fragmentation is a much larger problem for us than for many others. In my experience, mtrace is lightweight enough to not noticeably perturb the heap structure over the course of the program, usually allowing me to pinpoint which alloc= ations are leading to fragmentation. Heavier instrumentation, such as valgrind, messes with it far too much to isolate which allocations from the applicati= on are actually causing fragmentation when the instrumentation is not present, making them much less useful to me. > 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: > > =3D=3D7440=3D=3DERROR: 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. Does it have a noticeable impact on the layout of the heap compared to non-instrumented runs? Steven Vormwald