Bug 1304870 - eu-strip: invalid section alignment while stripping debuginfo from executables
eu-strip: invalid section alignment while stripping debuginfo from executables
Product: Red Hat Developer Toolset
Classification: Red Hat
Component: elfutils (Show other bugs)
DTS 4.1 RHEL 6
All Linux
medium Severity medium
: alpha
: 4.1
Assigned To: Mark Wielaard
Martin Cermak
: Regression
Depends On: 1303845 1304873
  Show dependency treegraph
Reported: 2016-02-04 15:46 EST by Mark Wielaard
Modified: 2016-05-31 04:39 EDT (History)
12 users (show)

See Also:
Fixed In Version: devtoolset-4-elfutils-0.165-4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1303845
Last Closed: 2016-05-31 04:39:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mark Wielaard 2016-02-04 15:46:23 EST
+++ This bug was initially created as a clone of Bug #1303845 +++

Description of problem:
On RHEL6.8 compose, my test package failed to build from src rpm because of eu-strip reported "invalid section alignment" when stripping debuginfo from built binaries.

extracting debug info from /root/rpmbuild/BUILDROOT/xfstests-20160111-1.git.x86_64/var/lib/xfstests/src/aio-dio-regress/aio-dio-subblock-eof-read
eu-strip: while writing '/root/rpmbuild/BUILDROOT/xfstests-20160111-1.git.x86_64/usr/lib/debug/var/lib/xfstests/src/aio-dio-regress/aio-dio-subblock-eof-read.debug.9QEhnw': invalid section alignment
error: Bad exit status from /var/tmp/rpm-tmp.D9kBkn (%install)

It can be reproduced by compiling the C file by hand and call eu-strip.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. compile attached c file: gcc -g aio-dio-subblock-eof-read.c -laio -o testprog
2. eu-strip testprog

Actual results:
[root@dhcp-66-86-3 xfstests]# eu-strip testprog
eu-strip: while writing 'testprog': invalid section alignment

Expected results:
no error

Additional info:
The same package can be built on RHEL6.7 distrobution. And I'm not sure if this really is a elfutils issue, but that's where it fails.

--- Additional comment from RHEL Product and Program Management on 2016-02-02 03:42:26 EST ---

This bugzilla has Keywords: Regression or TestBlocker.

Since no regressions or test blockers are allowed between releases,
it is also being [proposed|marked] as a blocker for this release.

Please resolve ASAP.

--- Additional comment from Mark Wielaard on 2016-02-02 04:29:43 EST ---

Thanks for the report. I don't currently have a 6.8 setup. I will set one up. But could you attach the testprog binary too if it isn't too big?

Could you also try eu-strip --permissive

      --permissive           Relax a few rules to handle slightly broken ELF

I thought that the rpm build scripts used --permissive, but if I am wrong about that, or if the issue is also reproducible with --permissive then this is certainly a regression.

--- Additional comment from Eryu Guan on 2016-02-02 05:41:57 EST ---

Still reproducible with --permissive option

[root@dhcp-66-86-3 xfstests]# eu-strip --permissive testprog
eu-strip: while writing 'testprog': invalid section alignment

--- Additional comment from Eryu Guan on 2016-02-02 05:42 EST ---

--- Additional comment from Eryu Guan on 2016-02-02 05:44:24 EST ---

And I was trying to build this src rpm

rpmbuild --rebuild xfstests-20160111-1.git.src.rpm


--- Additional comment from Mark Wielaard on 2016-02-03 17:26:14 EST ---

Looks like this regression was introduced by me in elfutils-0.162 (RHEL 6.7 has 0.161). Note the last part between ==> and <==

commit c0748eff8473b0caa6d51812aa31349bf1dce042
Author: Mark Wielaard <mjw@redhat.com>
Date:   Tue May 12 15:28:06 2015 +0200

    libelf: More checking of valid sh_addralign values.
    There were two issues with bogus sh_addralign values. First we would only
    check the individual Elf_Data d_align values were powerof2. But not the
    actual shdr addralign value. This would cause an issue if the shdr addralign
    was bigger than all of the individual d_align values. Then we could write
    out a bogus (! powerof2) shdr addralign value for the sections. Secondly
    when reading in the Elf_Data we would set the d_align value to the value
    of the shdr addralign value. But we would not check it was valid at all.
    In practice there are ELF files with incorrect sh_addralign values (they
    are a powerof2, but aren't aligned to the ELF image offset). We would try
    to fix that up in elf_update by adding extra padding. But this could bloat
    the ELF image a lot for large alignment values. So for too large alignments
    that are bigger than the offset in the ELF file clamp them to the offset
    value. ==> This could lead us to reject to write out the data again when the
    offset was not a powerof2. But this will only happen for aligment values
    bigger than 64. Which are uncommon in practice. <== 
    Signed-off-by: Mark Wielaard <mjw@redhat.com>

Which triggers for this sections:

[25] .bss                 NOBITS       0000000000601000 00000fd4 00002000  0 WA     0   0 4096

Alignment is 4096, but offset in the file is 4052 (0x0fd4). So the d_align gets clamped at 4052. Which then gets rejected when writing this section out again because that isn't a power of 2.

--- Additional comment from Mark Wielaard on 2016-02-04 04:04:32 EST ---

I posted a fix and new testcase upstream:

--- Additional comment from errata-xmlrpc on 2016-02-04 11:23:00 EST ---

Bug report changed to ON_QA status by Errata System.
A QE request has been submitted for advisory RHEA-2015:21950-01
Comment 4 Martin Cermak 2016-03-18 09:25:36 EDT
Verified against devtoolset-4-elfutils-0.165-7.el[67].
Comment 6 errata-xmlrpc 2016-05-31 04:39:57 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.