Created attachment 1704969 [details]
build.log

file build.log too big, will only attach last 32768 bytes

Created attachment 1704970 [details]
root.log

file root.log too big, will only attach last 32768 bytes

Created attachment 1704971 [details]
state.log

This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

It seems that some of the tests are crashing on armv7hl and ppc64le. On armv7hl, the tests test-perror2 and test-strerror_r reliably crash. On ppc64le, the test test-float reliably crashes. This was not introduced by grep 3.4 - the same happens if you try to build grep 3.3 on current F33, and the crashes *don't* happen if you build grep 3.4 on F32. So the crashes have been triggered by something in the build chain being updated in F33+, most likely GCC or glibc or something.

The test-perror2 failure reproduces under valgrind on x86-64:

==20== Invalid read of size 1
==20==    at 0x483DAB4: strcmp (vg_replace_strmem.c:847)
==20==    by 0x109414: main (test-perror2.c:84)
==20==  Address 0x4a1a3d0 is 0 bytes inside a block of size 17 free'd
==20==    at 0x483A9F5: free (vg_replace_malloc.c:538)
==20==    by 0x48E2134: strerror_l (in /usr/lib64/libc-2.32.so)
==20==    by 0x109328: main (test-perror2.c:72)
==20==  Block was alloc'd at
==20==    at 0x4839809: malloc (vg_replace_malloc.c:307)
==20==    by 0x48CA03F: __vasprintf_internal (in /usr/lib64/libc-2.32.so)
==20==    by 0x48A46F9: asprintf (in /usr/lib64/libc-2.32.so)
==20==    by 0x48E2184: strerror_l (in /usr/lib64/libc-2.32.so)
==20==    by 0x1092E2: main (test-perror2.c:67)
==20== 
==20== Invalid read of size 1
==20==    at 0x483DAC8: strcmp (vg_replace_strmem.c:847)
==20==    by 0x109414: main (test-perror2.c:84)
==20==  Address 0x4a1a3d1 is 1 bytes inside a block of size 17 free'd
==20==    at 0x483A9F5: free (vg_replace_malloc.c:538)
==20==    by 0x48E2134: strerror_l (in /usr/lib64/libc-2.32.so)
==20==    by 0x109328: main (test-perror2.c:72)
==20==  Block was alloc'd at
==20==    at 0x4839809: malloc (vg_replace_malloc.c:307)
==20==    by 0x48CA03F: __vasprintf_internal (in /usr/lib64/libc-2.32.so)
==20==    by 0x48A46F9: asprintf (in /usr/lib64/libc-2.32.so)
==20==    by 0x48E2184: strerror_l (in /usr/lib64/libc-2.32.so)
==20==    by 0x1092E2: main (test-perror2.c:67)

Likewise the test-strerror_r failure:

==21== Invalid read of size 1
==21==    at 0x483DAB4: strcmp (vg_replace_strmem.c:847)
==21==    by 0x109660: main (test-strerror_r.c:170)
==21==  Address 0x4a1a1b0 is 0 bytes inside a block of size 17 free'd
==21==    at 0x483A9F5: free (vg_replace_malloc.c:538)
==21==    by 0x48E2134: strerror_l (in /usr/lib64/libc-2.32.so)
==21==    by 0x1095B7: main (test-strerror_r.c:161)
==21==  Block was alloc'd at
==21==    at 0x4839809: malloc (vg_replace_malloc.c:307)
==21==    by 0x48CA03F: __vasprintf_internal (in /usr/lib64/libc-2.32.so)
==21==    by 0x48A46F9: asprintf (in /usr/lib64/libc-2.32.so)
==21==    by 0x48E2184: strerror_l (in /usr/lib64/libc-2.32.so)
==21==    by 0x10958B: main (test-strerror_r.c:156)
==21== 
==21== Invalid read of size 1
==21==    at 0x483DAC8: strcmp (vg_replace_strmem.c:847)
==21==    by 0x109660: main (test-strerror_r.c:170)
==21==  Address 0x4a1a1b1 is 1 bytes inside a block of size 17 free'd
==21==    at 0x483A9F5: free (vg_replace_malloc.c:538)
==21==    by 0x48E2134: strerror_l (in /usr/lib64/libc-2.32.so)
==21==    by 0x1095B7: main (test-strerror_r.c:161)
==21==  Block was alloc'd at
==21==    at 0x4839809: malloc (vg_replace_malloc.c:307)
==21==    by 0x48CA03F: __vasprintf_internal (in /usr/lib64/libc-2.32.so)
==21==    by 0x48A46F9: asprintf (in /usr/lib64/libc-2.32.so)
==21==    by 0x48E2184: strerror_l (in /usr/lib64/libc-2.32.so)
==21==    by 0x10958B: main (test-strerror_r.c:156)

Both are masked by malloc behavior with a 16-byte heap alignment (only armhfp has 8-byte heap alignment). I reported it to gnulib here: https://lists.gnu.org/archive/html/bug-gnulib/2020-08/msg00220.html

I believe Jakub has fixed the test-float issue on POWER in upstream GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95450

Thanks Florian, good work. It was on my todo list, but unfortunately I wasn't able to get to it :)

The fix for the test-float issues on ppc64 are supposed to be in the next gcc build according to a recent discussion between Jakub and myself.

Thanks! So if I'm getting this right, the test-float bug is a genuine toolchain (gcc) issue, so we should wait for the gcc fix before rebuilding grep. It looks like the fix is in gcc-10.2.1-3 which was built for Rawhide yesterday and is building for F33 right now?

The other two bugs are in the tests themselves, so it would be OK to just disable those two tests on armv7hl to get the build through, if no-one provides a fix for the tests in time (I'm not gonna attempt that with my C skills :P) Right? Thanks again.

Yes, the test-float is a gcc bug.  I believe the gcc build is waiting on s390x (big surprise there).

For the others I'd disable LTO for the entire build on the affected architecture.
%ifarch armv7hl
%define _lto_cflags %{nil}
%endif

That style is caught by my .spec file scanner that searches for LTO opt-outs that need deeper investigation.

Awesome. Thanks. Will do that.

Build fails even with that :/ Not sure if it's because LTO isn't actually the problem, or if the spec using $RPM_OPT_FLAGS the way it does ignores the change to _lto_cflags.

https://koji.fedoraproject.org/koji/taskinfo?taskID=50339572

The build log doesn't contain `-flto=auto`, so I guess disabling LTO did work, but doesn't fix the tests.

FEDORA-2020-bc38b42372 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

OK, I just used the patch from Paul Eggert to remove the offending checks, in the end, and got a build through for Rawhide. F33 is still waiting on gcc to finish building on s390 :(

FEDORA-2020-81fea835a4 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-81fea835a4

FEDORA-2020-81fea835a4 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-81fea835a4`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-81fea835a4

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-81fea835a4 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2020-0dcd106c75 has been pushed to the Fedora ELN stable repository.
If problem still persists, please make note of it in this bug report.