From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129255 invoked by alias); 13 Nov 2018 17:29:49 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 129221 invoked by uid 89); 13 Nov 2018 17:29:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=UD:wildebeest.org X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 13 Nov 2018 17:29:45 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 75F963000985 for ; Tue, 13 Nov 2018 18:29:43 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 315C4413CD4B; Tue, 13 Nov 2018 18:29:43 +0100 (CET) Message-ID: Subject: Re: Buildbot failure in Wildebeest Builder on whole buildset From: Mark Wielaard To: elfutils-devel@sourceware.org Date: Tue, 13 Nov 2018 17:29:00 -0000 In-Reply-To: <20181113164212.5C1789128B5@builder.wildebeest.org> References: <20181113164212.5C1789128B5@builder.wildebeest.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-2.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2018-q4/txt/msg00120.txt.bz2 On Tue, 2018-11-13 at 16:42 +0000, buildbot@builder.wildebeest.org wrote: > The Buildbot has detected a failed build on builder whole buildset > while building elfutils. > Full details are available at: > https://builder.wildebeest.org/buildbot/#builders/3/builds/299 This is disappointing. You fix one bug and find another :) The issue here is (when running the testsuite under gcc undefinedness sanitizer): runtest testfile-debug-rel-ppc64-z.o ../../../libelf/gelf_xlate.h:53:1: runtime error: member access within misaligned address 0x00000402928d for type 'struct Elf64_Chdr', which requires 8 byte alignment 0x00000402928d: note: pointer points here 1d bb 0a c3 01 00 00 00 00 00 00 00 71 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 78 9c 63 60 ^=20 *** failure strip testfile-debug-rel-ppc64-z.o ../../../libelf/gelf_xlate.h:53:1: runtime error: member access within misaligned address 0x000004029175 for type 'struct Elf64_Chdr', which requires 8 byte alignment 0x000004029175: note: pointer points here 1d bb 0a c3 01 00 00 00 00 00 00 00 71 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 78 9c 63 60 ^=20 *** failure strip --reloc-debug-sections testfile-debug-rel-ppc64-z.o This happens when writing out the file to disk. The section is compressed, and we try to write it back to disk, for this we need to translate the on disk Elf_Chdr (because it is a big endian ELF file and the memory representation on x86_64 is little endian): #1 0x00007ffff7f8ad98 in Elf64_cvt_Chdr (encode=3D,=20 len=3D, src=3D, dest=3D) at gelf_xlate.h:37 #2 Elf64_cvt_chdr (dest=3D, src=3D0x439380, len=3D69,=20 encode=3D) at chdr_xlate.h:32 #3 0x00007ffff7f9fd96 in __elf64_updatemmap (elf=3Delf@entry=3D0x4377c0,=20 change_bo=3Dchange_bo@entry=3D1, shnum=3Dshnum@entry=3D22) at elf32_updatefile.c:368 #4 0x00007ffff7f98a3d in write_file (shnum=3D22, change_bo=3D1, size=3D287= 2,=20 elf=3D0x4377c0) at elf_update.c:121 #5 elf_update (elf=3D0x4377c0, cmd=3Dcmd@entry=3DELF_C_WRITE) at elf_updat= e.c:231 #6 0x000000000040bd29 in handle_elf (fd=3D3, elf=3D, mode= =3D436,=20 tvp=3D0x0, prefix=3D0x0) at strip.c:2448 #7 0x000000000040f4be in process_file ( fname=3D0x7fffffffdbab "testfile-debug-rel-ppc64-z.o") at strip.c:769 #8 0x0000000000402bdf in main (argc=3D5, argv=3D0x7fffffffd848) at strip.c= :265 The compressed sections however simply have an alignment of 1. I think this is really a bug in binutils gas which produced this particular testfile. But it looks like we make the same mistake (decompressing and recompressing with eu-elfcompress produces the same misaligned compressed section). So we might actually have two bugs. 1) we don't handle incorrectly aligned compressed sections and 2) we generate such incorrectly aligned compressed sections ourselves. Pondering fixes. Cheers, Mark