From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41859 invoked by alias); 5 Apr 2018 20:21:41 -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 41834 invoked by uid 89); 5 Apr 2018 20:21:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=3035, 3030, odd X-HELO: mail-qt0-f180.google.com Received: from mail-qt0-f180.google.com (HELO mail-qt0-f180.google.com) (209.85.216.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Apr 2018 20:21:39 +0000 Received: by mail-qt0-f180.google.com with SMTP id s2so28345619qti.2 for ; Thu, 05 Apr 2018 13:21:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=oDocLGRO7j2VL0raP+GQhmFAXvJtK1hbxChLLeFKFfI=; b=K69K2AHbTKMvKo3QFmE4Xd4Dz+4MCb4v5rCFWTTlIC/tsXuo1kRNtryF2QCHyKO3aG ywunC15rH5jcC+3sGddD9jn5prxNSyUnBvQKli5JigGaZ+eGndovQc6nXuZgKKezKKNs c4dkXfz08JcEppsKXMQXI92t+wRD/I93zRUN4teFIDMvWbikXB3JGq8flENzIA+Gtw7Q nXbRUy3zw5vNQJrDyN2PKxf6IvRvLpDHoUPKw4ZaQG657IxLEfDR4hZB0hd4OdnUgwAa VYfsvseIpqp2rZFgWAGR8CKiUsfuijfchY8nVPaYUXLpW08jJ51hzkyAmyzDOuj8xknI cXzw== X-Gm-Message-State: ALQs6tAj2ABDTI+Fac0TU2daZqErXO4gUJFh0NEkpgEX4KCz4TmiLjR8 MjweYycMd2B6mv9ankK+Yso5iA== X-Google-Smtp-Source: AIpwx48MTAOF6ZebVl9CyGl1mGxyNHrSUEotX/MsELfuxURoFeTxYBaWjca02dZ5o9hUJZ1HvT/JCA== X-Received: by 10.200.42.146 with SMTP id b18mr34134078qta.262.1522959697337; Thu, 05 Apr 2018 13:21:37 -0700 (PDT) Received: from [10.150.73.190] (217.sub-174-207-1.myvzw.com. [174.207.1.217]) by smtp.gmail.com with ESMTPSA id p128sm6407443qkb.67.2018.04.05.13.21.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Apr 2018 13:21:36 -0700 (PDT) Subject: Re: glibc 2.26 mtrace broken, missing allocations To: Stefani Seibold , libc-help@sourceware.org, DJ Delorie References: <1522958519.9141.11.camel@seibold.net> From: Carlos O'Donell Message-ID: <33298b52-27e5-636b-03e2-799be2b9c0f5@redhat.com> Date: Thu, 05 Apr 2018 20:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1522958519.9141.11.camel@seibold.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-04/txt/msg00009.txt.bz2 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(). DJ, You've been poking at this area, any thoughts? -- Cheers, Carlos.