On 2025-03-19 11:42, Matthias Klose wrote:
On 18.03.25 20:56, Aurelien Jarno wrote:
This is fully reproducible when glibc 2.41-6 is built with gcc-14
14.2.0-18 or 14.2.0-19. On the contrary the problem disappears when
rebuilding glibc 2.41-6 with gcc-14 14.2.0-17 currently in testing. In
turn this prevent glibc 2.41-6 to migrate to testing.
I am not yet sure this is a GCC issue. a glibc 2.41-1 built with
gcc-14 14.2.0-18 doesn't show that behavior. -19 just addresses one
Ada issue and two C++ issues.
This does not match my tests. I have tried a second time after you
mentioned you can't reproduce it with glibc 2.41-1 in the previous
message and I *do* reproduce the issue with glibc 2.41-1, 2.41-4,
2.41-6.
Looking at the failing autopkg test: It passes when not run under
valgrind (on amdahl).
I confirm that the autopkg test only fails when run under valgrind. It
could mean that the glibc breakage affects valgrind and not the tested
package.
Are there glibc changes in glibc, which could
cause valgrind to fail?
There are absolutely no change in glibc. You can take glibc version
2.41-1, 2.41-4, or 2.41-6, build it with gcc-14 14.2.0-17, the
autopkgtest passes. Build it with 14.2.0-18, the autopkgtest fails.
I also see that valgrind has not been rebuilt for the new glibc
version. Is this necessary?
I do not see why it would be necessary. Anyway I just tried (after
patching it to workaround the unrelated FTBFS failure) and that doesn't
change anything.
The bug is very difficult to debug due to valgrind being involved.
Despite many tries I haven't been able to reproduce it outside of
valgrind. The problem disappears with gcc-13 13.3.0-13, but is still
there with gcc-15 15-20250315-1.
So far my finding are quite limited. It seems the new GCC generates more
optimized code in general, and especially for the memmem() function, and
that changes the location of the memmove() function located just after
in the binary. Aligning it to 6 bits seems to fix the problem with -18
(it is aligned to 5 bits), but strangely it is only aligned to 4 bits
with -17... Also padding it with the same number of nops at the
beginning of the function doesn't help, so this somehow excludes
alignment issues of functions located after it. Overall it seems that
memmove() wrongly jumps to memcpy() for cases it shouldn't, but I don't
really see why and while alignment would matter.
I am puzzled by all of that I and don't really know how to debug that
further.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
