Hi, Some recent glibc hardening updates broke valgrind on arm32. The fix was easy, but it could have been caught earlier. I have CCed Stef Walter since he is the contact for https://fedoraproject.org/wiki/CI and they might have ideas for a better way to do this (see below). But for now I would suggest the following patch for the glibc.spec file: diff --git a/glibc.spec b/glibc.spec index 5e8486a..ecb41c0 100644 --- a/glibc.spec +++ b/glibc.spec @@ -2042,7 +2042,8 @@ pushd build-%{target} LD_SHOW_AUXV=1 elf/ld.so --library-path .:elf:nptl:dlfcn /bin/true %if %{with valgrind} -elf/ld.so --library-path .:elf:nptl:dlfcn /usr/bin/valgrind \ +elf/ld.so --library-path .:elf:nptl:dlfcn \ + /usr/bin/valgrind --error-exitcode=1 \ elf/ld.so --library-path .:elf:nptl:dlfcn /usr/bin/true %endif popd That makes sure that not only is valgrind run on /bin/true, but also that no errors are produced by valgrind. There really should be none for /bin/true, if there are any that would mean such error/warnings would show up for each and every program run under valgrind, and that is really just noise. I put something similar in the valgrind.spec file and it passes on all rawhide arches. Stef, the above spec file snippet (and a similar variant in the valgrind.spec) is done during %check to make sure that the newly build glibc and/or newly build valgrind works as expected. Updates to glibc sometimes break valgrind because valgrind has some very specific startup requirements that rely on some specific functions in the dynamic loader being called in specific order. This is almost always a bug in valgrind, but we would like to catch these early and often. This is especially helpful on secondary architectures where catching these issues might otherwise take some time because there are less users. valgrind is similarly "fragile" when it comes to updates to the kernel (auxv changes, glibc may start calling new syscalls that valgrind doesn't recognize yet, etc.) and gcc updates (there might be a new optimization that generate code patterns valgrind/memcheck doesn't recognize). So I was wondering if the CI effort could help us here. Putting the test in the spec file %check of the packages is really helpful. But maybe it would be more helpful if such a check could be run on a new compose on all architectures whenever one of these packages is updated by the new Fedora CI initiative. Currently only glibc and valgrind have this cross check, updates to gcc or the kernel are only caught later when glibc or valgrind are rebuild.

Quick ping, and updated glibc.spec patch.

On Wed, 2017-07-12 at 14:46 +0200, Stef Walter wrote: > On 07.07.2017 10:59, Mark Wielaard wrote: > > Some recent glibc hardening updates broke valgrind on arm32. The > > fix was > > easy, but it could have been caught earlier. I have CCed Stef > > Walter > > since he is the contact for https://fedoraproject.org/wiki/CI and > > they > > might have ideas for a better way to do this (see below). > > > > But for now I would suggest the following patch for the > > glibc.spec file: > > > > diff --git a/glibc.spec b/glibc.spec > > index 5e8486a..ecb41c0 100644 > > --- a/glibc.spec > > +++ b/glibc.spec > > @@ -2042,7 +2042,8 @@ pushd build-%{target} > >  LD_SHOW_AUXV=1 elf/ld.so --library-path .:elf:nptl:dlfcn > > /bin/true > >   > >  %if %{with valgrind} > > -elf/ld.so --library-path .:elf:nptl:dlfcn /usr/bin/valgrind \ > > +elf/ld.so --library-path .:elf:nptl:dlfcn \ > > +       /usr/bin/valgrind --error-exitcode=1 \ > >         elf/ld.so --library-path .:elf:nptl:dlfcn /usr/bin/true > >  %endif > >  popd > > > > That makes sure that not only is valgrind run on /bin/true, but > > also > > that no errors are produced by valgrind. There really should be > > none > > for /bin/true, if there are any that would mean such > > error/warnings > > would show up for each and every program run under valgrind, and > > that is > > really just noise. > > > > I put something similar in the valgrind.spec file and it passes > > on all > > rawhide arches. > > [...] > > Putting the test in the spec file %check of the packages is > > really > > helpful. But maybe it would be more helpful if such a check could > > be run > > on a new compose on all architectures whenever one of these > > packages is > > updated by the new Fedora CI initiative. Currently only glibc and > > valgrind have this cross check, updates to gcc or the kernel are > > only > > caught later when glibc or valgrind are rebuild. > > Indeed. I agree that %check is a good place to start. Could someone apply the attached patch to the glibc.spec to have this. (Also included a change for the valgrind BuildRequires from file based to package based.) Thanks, Mark