Bug 2161595
| Summary: | Invalid read of size 4 in _Unwind_RaiseException (in /usr/lib64/libgcc_s-13-20230115.so.1) on ppc64le according to valgrind. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mattias Ellert <mattias.ellert> |
| Component: | gcc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | aoliva, davide, dmalcolm, fweimer, jakub, jlaw, jwakely, mcermak, mjw, mpolacek, msebor, nickc, rjones, sipoyare |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | ppc64le | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-01-23 11:31:37 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Mattias Ellert
2023-01-17 11:06:46 UTC
Any way to run just that single failing test? (In reply to Jakub Jelinek from comment #1) > Any way to run just that single failing test? scp -p HepMC3-3.2.5-5.fc38.src.rpm ppc64le-test.fedorainfracloud.org: ssh ppc64le-test.fedorainfracloud.org mock --root fedora-rawhide-ppc64le HepMC3-3.2.5-5.fc38.src.rpm mock --root fedora-rawhide-ppc64le --shell cd build/BUILD/HepMC3-3.2.5/redhat-linux-build/test/ /usr/bin/valgrind --trace-children=yes --leak-check=full --error-exitcode=1 --default-suppressions=yes --gen-suppressions=all ./testWeights exit mock --root fedora-rawhide-ppc64le --scrub all exit Seems this is caused by the -fno-omit-frame-pointer stuff. The libgcc unwinder can't work with that flag, __builtin_eh_return then doesn't work properly at least on powerpc64le. If unwind-dw2.c is rebuilt without -fno-omit-frame-pointer, the problem goes away. Put up https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/241 to exclude ppc64le from the frame pointers Change for the time being. FEDORA-2023-89e638afd7 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-89e638afd7 FEDORA-2023-89e638afd7 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report. Well, this particular bug isn't fixed by the redhat-rpm-config change, but after gcc is rebuilt with the frame pointers normally omitted at least in libgcc_eh.a(unwind-dw2.o) and libgcc_s.so.1. And, because of the libgcc_eh.a(unwind-dw2.o) case, we need that gcc in the buildroots before the mass rebuild. It will be in gcc-13.0.1-0.1.fc38. I've verified this is fixed in gcc-13.0.1-0.1.fc38 (which is still building but finished already on ppc64le and aarch64). https://koji.fedoraproject.org/koji/taskinfo?taskID=96265376 Should be fixed in rawhide. So I believe the change you made in gcc actually disables frame pointers almost everywhere, certainly for the gcc binary itself? If this is fixed now in redhat-rpm-config can that change be reverted? (By "everywhere" I mean, on every architecture) This change specifically: https://src.fedoraproject.org/rpms/gcc/c/311655b816f6039baa85db3c5f42a8adc41ff1ed?branch=rawhide How this could be fixed in redhat-rpm-config? There are simply sources in libgcc which must not be compiled with frame pointers on. That doesn't mean gcc when compiling other packages with redhat-rpm-config optflags doesn't force frame pointers on the compiled code. Why would you need frame pointer in the gcc compiler binaries? There is no point to system-wide profile the compiler, compilations should be reproduceable, so if something takes too long to compile and anybody wants to profile the compiler, it can be done with simple -ftime-report or callgrind etc. Reminds me, I believe this bogus -fno-omit-frame-pointer mess has been accepted on the condition that the proponents will show in a year that the slow down caused by it will pay back in speedups enabled by system wide profiling benefits. Has anyone come up with something that would pay at least for 10% of the slowdown so far? > Why would you need frame pointer in the gcc compiler binaries? > There is no point to system-wide profile the compiler, compilations > should be reproduceable, so if something takes too long to compile and > anybody wants to profile the compiler, This is exactly what I was trying to do. However without frame pointers I can't get good stack traces, so ... > it can be done with simple > -ftime-report or callgrind etc. This unfortunately doesn't work well when you're trying to profile the whole system (in this case, Koji). > that would pay at least for 10% of the slowdown so far? There's no evidence that's been shown to me of a 10% slowdown. My testing shows (under) 1%. However we have been using it (gradually) to profile the whole system. |