Description of problem: After gcc was updated to gcc 13, a test in the HepMC3 package started failing on ppc64le. The test uses valgrind. The reported failure is an Invalid read in the _Unwind_RaiseException function in /usr/lib64/libgcc_s-13-20230115.so.1. Version-Release number of selected component (if applicable): gcc-c++-13.0.0-0.9.fc38 How reproducible: Always. Steps to Reproduce: 1. Rebuild the HepMC3 package in rawhide 2. See one of the tests fail on ppc64le Actual results: Valgrind reports errors in one of the tests on ppc64le Expected results: No errors. Additional info: Build log availabel from koschei's build in koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=96232783 The failure reported in koschei was first reported when gcc was updated to version 13. ==32182== Memcheck, a memory error detector ==32182== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==32182== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info ==32182== Command: ./testWeights ==32182== ==32182== Invalid read of size 4 ==32182== at 0x4DFB70C: _Unwind_RaiseException (in /usr/lib64/libgcc_s-13-20230115.so.1) ==32182== by 0x192587: HepMC3::GenEvent::weight(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (GenEvent.h:118) ==32182== by 0x190A57: main (testWeights.cc:56) ==32182== Address 0x1fff00e338 is on thread 1's stack ==32182== 536 bytes below stack pointer ==32182== { <insert_a_suppression_name_here> Memcheck:Addr4 fun:_Unwind_RaiseException fun:_ZN6HepMC38GenEvent6weightERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE fun:main } ==32182== Invalid read of size 8 ==32182== at 0x4DFB714: _Unwind_RaiseException (in /usr/lib64/libgcc_s-13-20230115.so.1) ==32182== by 0x192587: HepMC3::GenEvent::weight(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (GenEvent.h:118) ==32182== by 0x190A57: main (testWeights.cc:56) ==32182== Address 0x1fff00e350 is on thread 1's stack ==32182== 512 bytes below stack pointer ==32182== { <insert_a_suppression_name_here> Memcheck:Addr8 fun:_Unwind_RaiseException fun:_ZN6HepMC38GenEvent6weightERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE fun:main } ==32182== Invalid read of size 8 ==32182== at 0x4DFB718: _Unwind_RaiseException (in /usr/lib64/libgcc_s-13-20230115.so.1) ==32182== by 0x192587: HepMC3::GenEvent::weight(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (GenEvent.h:118) ==32182== by 0x190A57: main (testWeights.cc:56) ==32182== Address 0x1fff00e358 is on thread 1's stack ==32182== 504 bytes below stack pointer ==32182== { <insert_a_suppression_name_here> Memcheck:Addr8 fun:_Unwind_RaiseException fun:_ZN6HepMC38GenEvent6weightERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE fun:main } ==32182== Invalid read of size 8 ==32182== at 0x4DFB71C: _Unwind_RaiseException (in /usr/lib64/libgcc_s-13-20230115.so.1) ==32182== by 0x192587: HepMC3::GenEvent::weight(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (GenEvent.h:118) ==32182== by 0x190A57: main (testWeights.cc:56) ==32182== Address 0x1fff00e360 is on thread 1's stack ==32182== 496 bytes below stack pointer ==32182== { <insert_a_suppression_name_here> Memcheck:Addr8 fun:_Unwind_RaiseException fun:_ZN6HepMC38GenEvent6weightERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE fun:main } ==32182== Invalid read of size 8 ==32182== at 0x4DFB720: _Unwind_RaiseException (in /usr/lib64/libgcc_s-13-20230115.so.1) ==32182== by 0x192587: HepMC3::GenEvent::weight(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (GenEvent.h:118) ==32182== by 0x190A57: main (testWeights.cc:56) ==32182== Address 0x1fff00e368 is on thread 1's stack ==32182== 488 bytes below stack pointer ==32182== { <insert_a_suppression_name_here> Memcheck:Addr8 fun:_Unwind_RaiseException fun:_ZN6HepMC38GenEvent6weightERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE fun:main } ==32182== Invalid read of size 4 ==32182== at 0x4DFB740: _Unwind_RaiseException (in /usr/lib64/libgcc_s-13-20230115.so.1) ==32182== by 0x192587: HepMC3::GenEvent::weight(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (GenEvent.h:118) ==32182== by 0x190A57: main (testWeights.cc:56) ==32182== Address 0x1fff00e340 is on thread 1's stack ==32182== 528 bytes below stack pointer ==32182== { <insert_a_suppression_name_here> Memcheck:Addr4 fun:_Unwind_RaiseException fun:_ZN6HepMC38GenEvent6weightERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE fun:main } ==32182== Invalid read of size 4 ==32182== at 0x4DFB754: _Unwind_RaiseException (in /usr/lib64/libgcc_s-13-20230115.so.1) ==32182== by 0x192587: HepMC3::GenEvent::weight(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (GenEvent.h:118) ==32182== by 0x190A57: main (testWeights.cc:56) ==32182== Address 0x1fff00e348 is on thread 1's stack ==32182== 520 bytes below stack pointer ==32182== { <insert_a_suppression_name_here> Memcheck:Addr4 fun:_Unwind_RaiseException fun:_ZN6HepMC38GenEvent6weightERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE fun:main } ==32182== ==32182== HEAP SUMMARY: ==32182== in use at exit: 0 bytes in 0 blocks ==32182== total heap usage: 34 allocs, 34 frees, 85,340 bytes allocated ==32182== ==32182== All heap blocks were freed -- no leaks are possible ==32182== ==32182== For lists of detected and suppressed errors, rerun with: -s ==32182== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 0 from 0)
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.