Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1863830
Summary: | grep: FTBFS in Fedora rawhide/f33 | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Fedora Release Engineering <releng> | ||||||||
Component: | grep | Assignee: | Jaroslav Škarvada <jskarvad> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | unspecified | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | 33 | CC: | awilliam, fweimer, jakub, jskarvad, kasal, law, lkundrak | ||||||||
Target Milestone: | --- | Keywords: | Reopened | ||||||||
Target Release: | --- | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | grep-3.4-5.fc34 grep-3.4-5.fc33 grep-3.4-5.eln103 | Doc Type: | If docs needed, set a value | ||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2020-09-02 19:48:40 UTC | Type: | --- | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Bug Depends On: | |||||||||||
Bug Blocks: | 1803234, 1872913, 1872922 | ||||||||||
Attachments: |
|
Description
Fedora Release Engineering
2020-08-03 17:29:51 UTC
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. |