From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52273 invoked by alias); 5 Apr 2018 20:33:50 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 52262 invoked by uid 89); 5 Apr 2018 20:33:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=3035, 3030, odd X-HELO: www84.your-server.de Received: from www84.your-server.de (HELO www84.your-server.de) (213.133.104.84) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Apr 2018 20:33:48 +0000 Received: from [188.192.103.1] (helo=vger.local) by www84.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1f4BZq-0004Ie-Fh; Thu, 05 Apr 2018 22:33:46 +0200 Message-ID: <1522960423.11048.1.camel@seibold.net> Subject: Re: glibc 2.26 mtrace broken, missing allocations From: Stefani Seibold To: Carlos O'Donell , libc-help@sourceware.org, DJ Delorie Date: Thu, 05 Apr 2018 20:33:00 -0000 In-Reply-To: <33298b52-27e5-636b-03e2-799be2b9c0f5@redhat.com> References: <1522958519.9141.11.camel@seibold.net> <33298b52-27e5-636b-03e2-799be2b9c0f5@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-04/txt/msg00010.txt.bz2 On Thu, 2018-04-05 at 15:21 -0500, Carlos O'Donell wrote: > On 04/05/2018 03:01 PM, Stefani Seibold wrote: > > Hi, > > > > when using mtrace i get a report of a reallocation which has an > > address > > which was not reported. > > > > For example: > > > > @ /usr/lib64/libgobject- > > 2.0.so.0:(g_signal_newv+0x23d)[0x7ffff7eb409d] - 0x5555559344c0 > > @ /usr/lib64/libglib-2.0.so.0:(g_malloc+0x19)[0x7ffff7244039] + > > 0x555555922d40 0x60 > > @ /usr/lib64/libglib-2.0.so.0:(g_realloc+0x20)[0x7ffff72440f0] < > > 0x5555558f0ea0 > > @ /usr/lib64/libglib-2.0.so.0:(g_realloc+0x20)[0x7ffff72440f0] > > > 0x5555558f0ea0 0x10 > > @ /usr/lib64/libglib-2.0.so.0:(g_realloc+0x20)[0x7ffff72440f0] < > > 0x5555558f0e70 > > > > The ingoing address 0x5555558f0ea0 for the realloc was not reported > > by > > an other alloc. > > That's odd. > > > The process (gvim -f) is single threaded and it is always the same > > address without address layout randomization. > > OK, so as a single-threaded process it should be perfectly safe to > use mtrace > (which is not MT-safe). > > > How is this possible? Are there allocation functions which are not > > traced by mtrace? > > I don't have any good answer for you. > > The allocation functions all have hooks into the hook functions which > are used > by mtrace. They are embedded into the libc.so.6 malloc API functions > directly > > e.g. > > 3026 void * > 3027 __libc_malloc (size_t bytes) > 3028 { > 3029 mstate ar_ptr; > 3030 void *victim; > 3031 > 3032 void *(*hook) (size_t, const void *) > 3033 = atomic_forced_read (__malloc_hook); > 3034 if (__builtin_expect (hook != NULL, 0)) > 3035 return (*hook)(bytes, RETURN_ADDRESS (0)); > > ... > > 3136 void *(*hook) (void *, size_t, const void *) = > 3137 atomic_forced_read (__realloc_hook); > 3138 if (__builtin_expect (hook != NULL, 0)) > 3139 return (*hook)(oldmem, bytes, RETURN_ADDRESS (0)); > > And happen right away and record the result. > > You should see *almost* all the results. > > In theory the early dynamic loader bootstrap uses dl-minimal.c which > has micro > allocator there for early bootstrap before libc.so.6's malloc can be > called, > but none of those addresses should ever leak into the post-bootstrap > for a realloc. > If such a thing did happen it would be a bug. > > You can try running mcheck() and associated functions to enable > additional checking. > Likewise mprobe(). > I just tried mcheck() and mcheck_pedantic(). No difference at all. > DJ, You've been poking at this area, any thoughts? >