Bug 1313404 - Test suite failure: elf/tst-audit10 and elf/tst-audit4
Test suite failure: elf/tst-audit10 and elf/tst-audit4
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Florian Weimer
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-01 09:38 EST by Carlos O'Donell
Modified: 2016-05-15 00:58 EDT (History)
9 users (show)

See Also:
Fixed In Version: glibc-2.22-15.fc23, glibc-2.23.1-7.fc24
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-15 00:58:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 19269 None None None 2016-03-01 09:52 EST
Sourceware 19860 None None None 2016-05-06 10:59 EDT

  None (edit)
Description Carlos O'Donell 2016-03-01 09:38:31 EST
On x86_64 we have two failures in tst-audit10 and tst-audit4.

version: 1
objopen: 0,
objopen: 0, /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/elf/ld-linux-x86-64.so.2
activity: add
objsearch: /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/elf/tst-auditmod10a.so, LA_SET_ORIG
objopen: 0, /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/elf/tst-auditmod10a.so
objsearch: libc.so.6, LA_SET_ORIG
objsearch: /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/libc.so.6, LA_SER_LIBPATH
objopen: 0, /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/libc.so.6
activity: consistent
symbind64: symname=__libc_start_main, st_value=0x7f89ce53bfd0, ndx=2118, flags=0
pltenter: symname=__libc_start_main, st_value=0x7f89ce53bfd0, ndx=2118, flags=0
preinit
symbind64: symname=mallopt, st_value=0x7f89ce5a6a60, ndx=1784, flags=0
pltenter: symname=mallopt, st_value=0x7f89ce5a6a60, ndx=1784, flags=0
symbind64: symname=getopt_long, st_value=0x7f89ce60f900, ndx=1439, flags=0
pltenter: symname=getopt_long, st_value=0x7f89ce60f900, ndx=1439, flags=0
symbind64: symname=getenv, st_value=0x7f89ce557230, ndx=1310, flags=0
pltenter: symname=getenv, st_value=0x7f89ce557230, ndx=1310, flags=0
symbind64: symname=strtoul, st_value=0x7f89ce558e80, ndx=1172, flags=0
pltenter: symname=strtoul, st_value=0x7f89ce558e80, ndx=1172, flags=0
pltenter: symname=getenv, st_value=0x7f89ce557230, ndx=1310, flags=0
symbind64: symname=setvbuf, st_value=0x7f89ce591e00, ndx=1882, flags=0
pltenter: symname=setvbuf, st_value=0x7f89ce591e00, ndx=1882, flags=0
symbind64: symname=__cxa_atexit, st_value=0x7f89ce557d20, ndx=815, flags=0
pltenter: symname=__cxa_atexit, st_value=0x7f89ce557d20, ndx=815, flags=0
pltenter: symname=getenv, st_value=0x7f89ce557230, ndx=1310, flags=0
symbind64: symname=fork, st_value=0x7f89ce5f0250, ndx=411, flags=0
pltenter: symname=fork, st_value=0x7f89ce5f0250, ndx=411, flags=0
symbind64: symname=signal, st_value=0x7f89ce552f20, ndx=398, flags=0
pltenter: symname=signal, st_value=0x7f89ce552f20, ndx=398, flags=0
symbind64: symname=alarm, st_value=0x7f89ce5f0110, ndx=1347, flags=0
pltenter: symname=alarm, st_value=0x7f89ce5f0110, ndx=1347, flags=0
pltenter: symname=signal, st_value=0x7f89ce552f20, ndx=398, flags=0
symbind64: symname=waitpid, st_value=0x7f89ce5eff70, ndx=1674, flags=0
pltenter: symname=waitpid, st_value=0x7f89ce5eff70, ndx=1674, flags=0
symbind64: symname=strsignal, st_value=0x7f89ce5af0d0, ndx=176, flags=0
pltenter: symname=strsignal, st_value=0x7f89ce5af0d0, ndx=176, flags=0
symbind64: symname=printf, st_value=0x7f89ce576200, ndx=603, flags=0
pltenter: symname=printf, st_value=0x7f89ce576200, ndx=603, flags=0
Didn't expect signal from child: got `Illegal instruction'
symbind64: symname=exit, st_value=0x7f89ce557ad0, ndx=128, flags=0
pltenter: symname=exit, st_value=0x7f89ce557ad0, ndx=128, flags=0
objclose
objclose
objclose
objclose

Notice the: "Didn't expect signal from child: got `Illegal instruction'"

version: 1
objopen: 0,
objopen: 0, /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/elf/ld-linux-x86-64.so.2
activity: add
objsearch: /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/elf/tst-auditmod4a.so, LA_SET_ORIG
objopen: 0, /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/elf/tst-auditmod4a.so
objsearch: libc.so.6, LA_SET_ORIG
objsearch: /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/libc.so.6, LA_SER_LIBPATH
objopen: 0, /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/libc.so.6
activity: consistent
symbind64: symname=__libc_start_main, st_value=0x7fba692eefd0, ndx=2118, flags=0
pltenter: symname=__libc_start_main, st_value=0x7fba692eefd0, ndx=2118, flags=0
preinit
symbind64: symname=mallopt, st_value=0x7fba69359a60, ndx=1784, flags=0
pltenter: symname=mallopt, st_value=0x7fba69359a60, ndx=1784, flags=0
symbind64: symname=getopt_long, st_value=0x7fba693c2900, ndx=1439, flags=0
pltenter: symname=getopt_long, st_value=0x7fba693c2900, ndx=1439, flags=0
symbind64: symname=getenv, st_value=0x7fba6930a230, ndx=1310, flags=0
pltenter: symname=getenv, st_value=0x7fba6930a230, ndx=1310, flags=0
symbind64: symname=strtoul, st_value=0x7fba6930be80, ndx=1172, flags=0
pltenter: symname=strtoul, st_value=0x7fba6930be80, ndx=1172, flags=0
pltenter: symname=getenv, st_value=0x7fba6930a230, ndx=1310, flags=0
symbind64: symname=setvbuf, st_value=0x7fba69344e00, ndx=1882, flags=0
pltenter: symname=setvbuf, st_value=0x7fba69344e00, ndx=1882, flags=0
symbind64: symname=__cxa_atexit, st_value=0x7fba6930ad20, ndx=815, flags=0
pltenter: symname=__cxa_atexit, st_value=0x7fba6930ad20, ndx=815, flags=0
pltenter: symname=getenv, st_value=0x7fba6930a230, ndx=1310, flags=0
symbind64: symname=fork, st_value=0x7fba693a3250, ndx=411, flags=0
pltenter: symname=fork, st_value=0x7fba693a3250, ndx=411, flags=0
symbind64: symname=signal, st_value=0x7fba69305f20, ndx=398, flags=0
pltenter: symname=signal, st_value=0x7fba69305f20, ndx=398, flags=0
symbind64: symname=alarm, st_value=0x7fba693a3110, ndx=1347, flags=0
pltenter: symname=alarm, st_value=0x7fba693a3110, ndx=1347, flags=0
pltenter: symname=signal, st_value=0x7fba69305f20, ndx=398, flags=0
symbind64: symname=waitpid, st_value=0x7fba693a2f70, ndx=1674, flags=0
pltenter: symname=waitpid, st_value=0x7fba693a2f70, ndx=1674, flags=0
symbind64: symname=strsignal, st_value=0x7fba693620d0, ndx=176, flags=0
pltenter: symname=strsignal, st_value=0x7fba693620d0, ndx=176, flags=0
symbind64: symname=printf, st_value=0x7fba69329200, ndx=603, flags=0
pltenter: symname=printf, st_value=0x7fba69329200, ndx=603, flags=0
Didn't expect signal from child: got `Illegal instruction'
symbind64: symname=exit, st_value=0x7fba6930aad0, ndx=128, flags=0
pltenter: symname=exit, st_value=0x7fba6930aad0, ndx=128, flags=0
objclose
objclose
objclose
objclose

Similarly for tst-audit4.

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel(R) Xeon(R) CPU           E5540  @ 2.53GHz
stepping        : 5
microcode       : 0x11
cpu MHz         : 1995.000
cache size      : 8192 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm dtherm tpr_shadow vnmi flexpriority ept vpid
bugs            :
bogomips        : 5066.89
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

There are 16 processors.

Perhaps we have avx instruction leakage into the dynamic loader? This is a serious issue that needs review.
Comment 2 Florian Weimer 2016-03-01 09:58:43 EST
As Joseph explained in the upstream bug, the tests is invalid.  We tell GCC to use instructions the host does not support:

AVX-CFLAGS=-mavx -mno-vzeroupper
CFLAGS-tst-audit4.c += $(AVX-CFLAGS)
CFLAGS-tst-auditmod4a.c += $(AVX-CFLAGS)
CFLAGS-tst-auditmod4b.c += $(AVX-CFLAGS)
CFLAGS-tst-auditmod6b.c += $(AVX-CFLAGS)
CFLAGS-tst-auditmod6c.c += $(AVX-CFLAGS)
CFLAGS-tst-auditmod7b.c += $(AVX-CFLAGS)
ifeq (yes,$(config-cflags-avx512))
AVX512-CFLAGS = -mavx512f
CFLAGS-tst-audit10.c += $(AVX512-CFLAGS)
CFLAGS-tst-auditmod10a.c += $(AVX512-CFLAGS)
CFLAGS-tst-auditmod10b.c += $(AVX512-CFLAGS)
endif
endif

And it turns out that sufficiently new GCC makes use of this permission.

I'm downgrading the urgency.  We need to fix this, but it is not a release blocker.

I'm going to ask for advice what we can do so that GCC can use the built-ins, but will not generate code for the new instructions.
Comment 3 Carlos O'Donell 2016-03-01 10:03:01 EST
(In reply to Florian Weimer from comment #2)
> I'm downgrading the urgency.  We need to fix this, but it is not a release
> blocker.

Agreed.

> I'm going to ask for advice what we can do so that GCC can use the
> built-ins, but will not generate code for the new instructions.

This test needs to be marked UNSUPPORTED if the host lacks the instructions to execute it, just like C++ tests etc.
Comment 4 Carlos O'Donell 2016-03-01 10:03:38 EST
(In reply to Carlos O'Donell from comment #3)
> > I'm going to ask for advice what we can do so that GCC can use the
> > built-ins, but will not generate code for the new instructions.
> 
> This test needs to be marked UNSUPPORTED if the host lacks the instructions
> to execute it, just like C++ tests etc.

Not host, but target rather (clarification required for cross-compiling).
Comment 5 Florian Weimer 2016-03-01 10:08:19 EST
(In reply to Carlos O'Donell from comment #3)
> (In reply to Florian Weimer from comment #2)
> > I'm downgrading the urgency.  We need to fix this, but it is not a release
> > blocker.
> 
> Agreed.
> 
> > I'm going to ask for advice what we can do so that GCC can use the
> > built-ins, but will not generate code for the new instructions.
> 
> This test needs to be marked UNSUPPORTED if the host lacks the instructions
> to execute it, just like C++ tests etc.

There already is a run-time CPU feature test which causes the actual testing to be skipped if the CPU lacks the required micro-architecture support.  This should be good enough.  It doesn't work because it runs too late.

Our test harness currently does not support marking tests as UNSUPPORTED at run time, unfortunately.  It's just not powerful enough.

Related gcc-help query: https://gcc.gnu.org/ml/gcc-help/2016-03/msg00003.html
Comment 6 Carlos O'Donell 2016-03-01 10:52:21 EST
(In reply to Florian Weimer from comment #5)
> (In reply to Carlos O'Donell from comment #3)
> > (In reply to Florian Weimer from comment #2)
> > > I'm downgrading the urgency.  We need to fix this, but it is not a release
> > > blocker.
> > 
> > Agreed.
> > 
> > > I'm going to ask for advice what we can do so that GCC can use the
> > > built-ins, but will not generate code for the new instructions.
> > 
> > This test needs to be marked UNSUPPORTED if the host lacks the instructions
> > to execute it, just like C++ tests etc.
> 
> There already is a run-time CPU feature test which causes the actual testing
> to be skipped if the CPU lacks the required micro-architecture support. 
> This should be good enough.  It doesn't work because it runs too late.
> 
> Our test harness currently does not support marking tests as UNSUPPORTED at
> run time, unfortunately.  It's just not powerful enough.

It does support UNSUPPORTED at run time. You must exit with reserved code 77 and scripts/evaluate-test.sh will mark it UNSUPPORTED. The test can do whatever testing it needs to determine at runtime (on the target) if it's unsupported.
Comment 7 Florian Weimer 2016-03-07 09:59:29 EST
Patch posted upstream:

https://sourceware.org/ml/libc-alpha/2016-03/msg00147.html
Comment 8 Fedora Update System 2016-05-07 13:18:56 EDT
glibc-2.22-15.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-68abc0be35
Comment 9 Fedora Update System 2016-05-08 12:25:08 EDT
glibc-2.22-15.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-68abc0be35
Comment 10 Florian Weimer 2016-05-09 05:57:50 EDT
New 2.23 backports:

commit 4cf055a2a331b7361622dc9ac8993b59c6f0ef59
Author: Florian Weimer <fweimer@redhat.com>
Date:   Fri Mar 25 11:11:42 2016 +0100

    tst-audit10: Fix compilation on compilers without bit_AVX512F [BZ #19860]
    
        [BZ# 19860]
        * sysdeps/x86_64/tst-audit10.c (avx512_enabled): Always return
        zero if the compiler does not provide the AVX512F bit.
    
    (cherry picked from commit f327f5b47be57bc05a4077344b381016c1bb2c11)

commit d603d94994a1d326ebc9e93c8be892acc834a114
Author: Roland McGrath <roland@hack.frob.com>
Date:   Tue Mar 8 12:31:13 2016 -0800

    Fix tst-audit10 build when -mavx512f is not supported.
    
    (cherry picked from commit 3bd80c0de2f8e7ca8020d37739339636d169957e)

commit 7fa9775594b1592dfcdad5bc32ea449882ca9d9a
Author: Florian Weimer <fweimer@redhat.com>
Date:   Mon Mar 7 16:00:25 2016 +0100

    tst-audit4, tst-audit10: Compile AVX/AVX-512 code separately [BZ #19269]
    
    This ensures that GCC will not use unsupported instructions before
    the run-time check to ensure support.
    
    (cherry picked from commit 3c0f7407eedb524c9114bb675cd55b903c71daaa)
Comment 11 Fedora Update System 2016-05-09 10:56:18 EDT
glibc-2.23.1-6.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b321728d74
Comment 12 Fedora Update System 2016-05-10 13:57:15 EDT
glibc-2.22-15.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Comment 13 Fedora Update System 2016-05-10 16:29:53 EDT
glibc-2.23.1-6.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-b321728d74
Comment 14 Fedora Update System 2016-05-11 09:54:34 EDT
glibc-2.23.1-7.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b321728d74
Comment 15 Fedora Update System 2016-05-12 05:43:48 EDT
glibc-2.23.1-7.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-b321728d74
Comment 16 Fedora Update System 2016-05-14 19:29:44 EDT
glibc-2.23.1-7.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

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