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.
Cheers,
Mark