From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129592 invoked by alias); 5 Apr 2018 20:52:18 -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 129579 invoked by uid 89); 5 Apr 2018 20:52:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy= X-HELO: mail-qt0-f181.google.com Received: from mail-qt0-f181.google.com (HELO mail-qt0-f181.google.com) (209.85.216.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Apr 2018 20:52:16 +0000 Received: by mail-qt0-f181.google.com with SMTP id s48so28400781qtb.10 for ; Thu, 05 Apr 2018 13:52:16 -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=3eUlRDkPXfP8xSwluy2+k2Flm6RBSdqw77BZtJhOy4Q=; b=D8tHIuDscCK1RbPA28JIO216yc4K9el+59zJGzuWcgQki+XHjQ0HIgMs1/rLDm4W+y v7xRQq+TapYZBUkGMTLtO7JOROFwuTryQTodKfWN3MMOpL/V7rn4s2JEcGQmY7xUqsn7 jDDAZsfiXnexaN3CJs0dIVka10g2kFf0XJcr2JL1AgseMQA+WrbVunzOV/cPbG5j4Hzb WmB9iWW8mMKl4OBrAy3dn99NthOS0dSevGwSWLNmTca98WQVVgzL8SH3Qdk6mtwAVorB OZO7JAhgU8VX+zk7aXA6luVOgI/gEOTGYl9wofmD6fAAD6ujMIRW8Tb3nr90Yh3qRNSe IRuQ== X-Gm-Message-State: ALQs6tD+SEiHn7bzXIDDM9/9b2v3mahruetSI7jHd2RnzNbRfc72BNiX DlgIlP8563DAfrP233cyJTK1nw== X-Google-Smtp-Source: AIpwx4/UyM+a6f6fEDThKxIxTnvLh3vtq8o5q8C04RV30Fz0gwC+K2moYGovcb4/YXQjEeYR86CVqg== X-Received: by 10.200.113.196 with SMTP id i4mr5112542qtp.186.1522961534691; Thu, 05 Apr 2018 13:52:14 -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 c20sm6251335qke.38.2018.04.05.13.52.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Apr 2018 13:52:13 -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> <33298b52-27e5-636b-03e2-799be2b9c0f5@redhat.com> <1522960423.11048.1.camel@seibold.net> From: Carlos O'Donell Message-ID: Date: Thu, 05 Apr 2018 20:52: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: <1522960423.11048.1.camel@seibold.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-04/txt/msg00011.txt.bz2 On 04/05/2018 03:33 PM, Stefani Seibold wrote: > I just tried mcheck() and mcheck_pedantic(). No difference at all. I assume also then that valgrind with full checking doesn't show any problems either? If that's the case then you would have to debug the application under trace and just count the malloc's to see where it came from. I'd be happy to help at that point if you did some of the heavy lifting to find the place the allocation comes from. -- Cheers, Carlos.