This is reported upstream as https://github.com/grpc/grpc/issues/33634 for gcc 13, but i experience it with (gentoo) gcc 12.2.1 Strangely enough, it emerges fine on another gentoo box with gcc (Gentoo 13.1.1_p20230527 p3) 13.1.1 20230527 The aforementionned ticked has a workaround. Reproducible: Always In file included from /tmp/portage/net-libs/grpc-1.57.0-r1/work/grpc-1.57.0/src/core/lib/channel/channelz.h:43, from /tmp/portage/net-libs/grpc-1.57.0-r1/work/grpc-1.57.0/src/core/lib/surface/channel.h:47, from /tmp/portage/net-libs/grpc-1.57.0-r1/work/grpc-1.57.0/src/core/lib/surface/call.h:51, from /tmp/portage/net-libs/grpc-1.57.0-r1/work/grpc-1.57.0/src/core/lib/channel/promise_based_filter.h:66, from /tmp/portage/net-libs/grpc-1.57.0-r1/work/grpc-1.57.0/src/core/lib/surface/lame_client.h:34, from /tmp/portage/net-libs/grpc-1.57.0-r1/work/grpc-1.57.0/src/core/ext/filters/client_channel/dynamic_filters.cc:38: /tmp/portage/net-libs/grpc-1.57.0-r1/work/grpc-1.57.0/src/core/lib/gprpp/per_cpu.h: In instantiation of ‘grpc_core::PerCpu<T>::PerCpu(grpc_core::PerCpuOptions) [with T = grpc_core::channelz::PerCpuCallCountingHelper::PerCpuData]’: /tmp/portage/net-libs/grpc-1.57.0-r1/work/grpc-1.57.0/src/core/lib/channel/channelz.h:182:70: required from here /tmp/portage/net-libs/grpc-1.57.0-r1/work/grpc-1.57.0/src/core/lib/gprpp/per_cpu.h:70:30: internal compiler error: Segmentation fault 70 | std::unique_ptr<T[]> data_{new T[cpus_]}; | ^~~~~~~~~~~~ Please submit a full bug report, with preprocessed source (by using -freport-bug). See <https://bugs.gentoo.org/> for instructions. ninja: build stopped: subcommand failed.
For the record. The box where ICE was happening uses: * dev-cpp/abseil-cpp-20230125.3-r1 * dev-libs/protobuf-23.3-r1 * gcc 12.2.1_p20230428-r1 Masking this 'fixed' the problem (and abseil was reverted to 20220623.1): >=net-libs/grpc-1.55.0 >=dev-libs/protobuf-22.0 The box where it works fine uses: * dev-cpp/abseil-cpp-20230125.3-r1 * dev-libs/protobuf-23.3-r1 * gcc 13.1.1_p20230527
You know well by now that the full build.log & emerge --info is needed for bugs :)
That's useful for debugging, but that's not needed here. The problem is known, there are upstream tickets both for grpc and gcc. For gentoo it's a matter of knowing what's compatible with what. GCC clearly has a bug (should never ICE). That seems to be fixed by https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0a2c771910e888c9a26db319122230144789b9bf I can confirm that gcc 13.1.1_p20230527 (as found in gentoo at least) does have the patch applied. That explains why it works on my second box (~amd64). I can also confirm the patch doesn't appear in source code for sys-devel/gcc-12.2.1_p20230428-r1, which in turn explains why it fails on the failing box (stable amd64). I'm slightly late on this box, the latest gcc on stable 'amd64' is 12.3.1_p20230526, but the patch doesn't seem to be applied here either, and not on 12.3.1_p20230623 (~amd64).
(In reply to Thomas Capricelli from comment #3) > That's useful for debugging, but that's not needed here. The problem is > known, there are upstream tickets both for grpc and gcc. For gentoo it's a > matter of knowing what's compatible with what. > It's useful because I can then quickly triage it and see what the problem is. In future, please always do it. > GCC clearly has a bug (should never ICE). That seems to be fixed by > Yes, I know. I spend a lot of time looking at bugs users report for that. > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > h=0a2c771910e888c9a26db319122230144789b9bf > > I can confirm that gcc 13.1.1_p20230527 (as found in gentoo at least) does > have the patch applied. That explains why it works on my second box (~amd64). > > I can also confirm the patch doesn't appear in source code for > sys-devel/gcc-12.2.1_p20230428-r1, which in turn explains why it fails on > the failing box (stable amd64). > Yes, I need to see what the first version is with the fix wrt 12, if it's even been backported upstream at all.
And to be even more clear: I need to be able to replicate the issue with the precise arguments you had so I can see if it still reproduces on tip of 12, etc.
Created attachment 868496 [details] portage/net-libs/grpc-1.57.0-r1/temp/build.log
Created attachment 868497 [details] emerge --info
Can you try keywording >=sys-devel/gcc-12.3.1_p20230811*:12?
It works, grpc-1.57.0-r1 emerged fine. gcc (Gentoo Hardened 12.3.1_p20230811 p2) 12.3.1 20230811 [ebuild N ] net-libs/grpc-1.57.0-r1 USE="-doc -examples -systemd -test" [ebuild N ] dev-libs/protobuf-23.3-r2 USE="zlib -emacs -examples -test" ABI_X86="(64) -32 (-x32)" [ebuild N ] dev-cpp/abseil-cpp-20230125.3-r1 USE="-test" ABI_X86="(64) -32 (-x32)"
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=28549e0b4f6c5da1319413b48d53a4b13890603a commit 28549e0b4f6c5da1319413b48d53a4b13890603a Author: Sam James <sam@gentoo.org> AuthorDate: 2023-08-26 23:27:53 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-08-26 23:28:17 +0000 sys-devel/gcc: keyword 12.3.1_p20230825 Bug: https://bugs.gentoo.org/911939 Bug: https://bugs.gentoo.org/912795 Signed-off-by: Sam James <sam@gentoo.org> sys-devel/gcc/gcc-12.3.1_p20230825.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
What is the status here? Why is it still blocking bug #912819?
Not sure. It currently works on my box with: sys-devel/gcc-13.2.1_p20231216 dev-cpp/abseil-cpp-20230802.0 dev-libs/protobuf-23.3-r2 net-libs/grpc-1.60.0 and until recently i was using net-libs/grpc-1.57.0-r1 and there was no problem either. In doubt, i'll close this one and re-open if needed.
