From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121565 invoked by alias); 22 May 2017 17:17:11 -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 121551 invoked by uid 89); 22 May 2017 17:17:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=spend, Monday, monday X-HELO: homiemail-a119.g.dreamhost.com Subject: Re: LD_HWCAP_MASK failure with tst-env-setuid To: Adhemerval Zanella , "libc-alpha@sourceware.org" Cc: Szabolcs Nagy References: <0ba0c258-1507-3ef4-d981-c034de61dc6f@gotplt.org> From: Siddhesh Poyarekar Message-ID: Date: Mon, 22 May 2017 17:17:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-05/txt/msg00657.txt.bz2 On Monday 22 May 2017 06:48 PM, Adhemerval Zanella wrote: > Hi Siddhesh, unfortunately the test is still failing on my x86_64 system > with LD_HWCAP_MASK=0xffffffff. I used you latest tunable patchset [1] > applies on top of master (402bf0695218bbe290418b9486b1dd5fe284d903) and > configure with: > > --host=x86_64-linux-gnu --build=x86_64-linux-gnu --enable-add-ons=libidn > --without-selinux --enable-stackguard-randomization --enable-obsolete-rpc > --enable-systemtap --enable-multi-arch --enable-lock-elision --enable-tunables > > However I am only seeing this issue on x86_64, aarch64 does not bail out > with 'cannot create capability list: Cannot allocate memory'. > > And using you analysis I tried to install the built glibc on a sysroot > and neither the 'bin/true' or the 'tst-env-setuid' failed with > LD_HWCAP_MASK=0xffffffff. So I think for BZ#21391 indeed fixed and your > suggestion about installed glibc messing up with the testing still > worries me. I think what might be happening in fact is static linked > binaries are still relying on ld.so.cache on some internal calculation, > which I think it is not the intended behaviour. I will try spend some > time figuring out why this is still fails on my system. OK I've found a box that exhibits this too and it is happening only with my patchset and not without. Let me dig as well. Siddhesh